BranchCache za mrežne dijeljene mape preko VPN-a: kada pomaže, a kada ne

Neko u timu kaže da je mrežna mapa preko VPN-a spora, a prvi predlog je uvijek keš. Prije nego što u dizajn udaljenog pristupa dodate BranchCache, razdvojite žalbu na jedan od tri oblika: ponovna preuzimanja nepromijenjenog sadržaja, otpremanja ili pregledanje s puno metapodataka kroz mape s hiljadama stavki. BranchCache rješava prvi oblik na podržanom sadržaju i ne čini ništa korisno za druga dva. To nije ograničenje koje treba zaobići; to je poređenje koje trebate napraviti prije nego što potrošite sedmicu na implementaciju.

Ista mapa, tri različite žalbe

Poslovnica u kojoj osam ljudi otvara isti nepromijenjeni video za obuku jeste slučaj za koji je funkcija napravljena. Prvo preuzimanje ide preko WAN-a, sadržaj se kešira blizu čitalaca, a kasnija preuzimanja istog nepromijenjenog fajla poslužuju se lokalno. Korist je stvarna i uska: isti sadržaj, nepromijenjen, više čitalaca.

Laptop koji otprema novi snimak preko kućne veze jeste suprotan slučaj. Nema prethodno keširane kopije fajla koji još ne postoji, pa otpremanje ide istim ograničenim putem kao i uvijek. Keš za preuzimanje ne uklanja otpremanje i nikakav izbor smještaja to ne mijenja.

Treći oblik je onaj koji razočara ljude jer izgleda kao problem s preuzimanjem. Otvaranje direktorija s desetinama hiljada fajlova, njegovo sortiranje i čitanje metapodataka je tok malih operacija, a ne ponovljeni prenos jednog velikog objekta. Keširanje tijela fajlova ne pomaže popisivanju.

Distribuirani keš: VPN bazen nije poslovna LAN mreža

U distribuiranom načinu rada klijentska računala dijele keširani sadržaj međusobno, a Microsoft taj način dokumentuje kao rad unutar jedne podmreže. VPN bazen klijenata nije podmreža u tom smislu čak i kada sve adrese izgledaju uzastopno: otkrivanje partnera, dostupnost klijent-klijent i dozvola za razmjenu keširanih podataka su odvojena pitanja, a uobičajeni dizajn udaljenog pristupa na sva tri odgovara sa ne.

Možete natjerati bazen da se ponaša kao poslovna LAN mreža dozvoljavajući promet između klijenata, ali to je sigurnosna odluka, a ne odluka o keširanju. Većina dizajna udaljenog pristupa izoluje klijente jedne od drugih upravo zato da jedan kompromitovani laptop ne može doći do drugog, a trampa te izolacije za pogodak u kešu je loša razmjena osim ako partneri već nisu pouzdani jednaki.

Za jednog korisnika koji putuje distribuirani način nema s kim dijeliti. Keš još može služiti ponovljena čitanja tog jednog klijenta, ali to je korist keša na strani klijenta, a ne korist od smještaja u poslovnici, i vrijedi to reći prije nego što neko očekuje da ured postane brži.

Hostirani keš: smještaj odlučuje hoće li pomoći

Hostirani keš stavlja zajednički keš na server, što je jedini način koji ima smisla između podmreža i jedini koji radi kada klijenti ne mogu razgovarati međusobno. Neposredno pitanje je gdje taj server stoji. Hostirani keš do kojeg se dolazi preko iste ograničene veze kao i do izvora premjestio je bajtove, a ne problem.

Postavite ga blizu čitalaca, dajte mu vlasnika i odredite veličinu diska za radni skup, a ne za cijelu mapu. Microsoftov pregled BranchCachea opisuje oba načina i ponašanje klijenta, uključujući dio koji ljudi zaboravljaju: klijenti se i dalje obraćaju izvoru za autorizaciju i informacije o sadržaju prije nego što upotrijebe keširane podatke.

Implementacija su tri uloge planirane zajedno, a ne jedna kvačica. Izvorni server objavljuje heševe za sadržaj, hostirani keš je omogućen i otkriv, a klijenti su konfigurisani da ga koriste. Na strani servera to je prepoznatljivo u PowerShellu:

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

Na klijentu ga ili usmjerite na imenovane servere ili mu dozvolite da ih otkrije preko točke veze usluge; zatim potvrdite način koji je stvarno odabrao umjesto da pretpostavljate da je pravilo primijenjeno:

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

Šta još stiže do izvora

Keširanje ne uklanja autorizaciju. Klijent bez dozvole za čitanje fajla ne dobija pristup zato što ga je neko drugi keširao, a izvor i dalje odgovara na pitanje autorizacije i daje informacije o sadržaju koje omogućavaju pretragu keša. Ako izvor nije dostupan, keširana kopija sama po sebi ne postaje mrežna mapa van mreže.

Promjene sadržaja takođe tiho ruše pretpostavku. Fajl koji je ponovo sačuvan, ponovo kodiran ili ga je dodirnuo proizvod za rezervne kopije možda više ne odgovara keširanom hešu, a sljedeće čitanje ide natrag na izvor. To je ispravno ponašanje i zato keš čiji se radni skup mijenja svakog sata daje malo.

Izbacivanje je treća granica. Keš je konačan, pa veliki radni skup istiskuje stariji sadržaj, a korist zavisi od toga da se ponovna čitanja dogode prije izbacivanja, a ne poslije. Određivanje veličine keša za cijelu mapu uobičajen je način da budete razočarani implementacijom koja je tehnički bila ispravna.

Prihvatite to s dva preuzimanja i jednim otpremanjem

Testirajte prava tri toka i zapišite šta svaki pokazuje. Prvo preuzimanje reprezentativnog fajla s klijenta, mjereno na vezi prema izvoru kao i na korisnikovom satu. Drugo preuzimanje istog nepromijenjenog fajla s drugog klijenta u istoj grupi smještaja. Jedno otpremanje novog fajla, koje ne treba pokazati poboljšanje i potvrđuje da se kešu ne pripisuje nešto što nikada nije uradio.

Ako drugo preuzimanje još prelazi vezu prema izvoru za većinu bajtova, keš se ne koristi, a uzrok je obično klijent u pogrešnom načinu rada, nedostajuće objavljivanje heševa na izvoru ili hostirani keš na pogrešnoj strani ograničene veze. To su tri različita popravka i samo jedan od njih se tiče mrežnog smještaja.

Zatim iznesite zaključak u istom obliku kao izvorna žalba: ponovna preuzimanja nepromijenjenog sadržaja s ovog izvora ovim čitaocima poslužuje ovaj keš. Sve ostalo u vezi s mapom ostaje netaknuto, uključujući otpremanja, popisivanje mapa i priču o radu van mreže, koja još treba svoj odgovor.