BranchCache за споделени VPN-папки: кога помага, а кога не

Некој во тимот вели дека споделената папка преку VPN е бавна, а првиот предлог е секогаш кеш. Пред да го додадете BranchCache во дизајнот за оддалечен пристап, поделете го проблемот во еден од три облици: повторени преземања на непроменета содржина, качувања или прелистување со многу метаподатоци низ папки со илјадници записи. BranchCache го решава првиот облик кај поддржана содржина и не прави ништо корисно за другите два. Тоа не е ограничување што треба да се заобиколи; тоа е споредбата што треба да ја направите пред да потрошите една недела на распоредување.

Истата споделена папка, три различни поплаки

Канцеларија во огранок каде осум луѓе отвораат исто непроменето видео за обука е случајот за кој е дизајнирана функцијата. Првото преземање поминува низ WAN, содржината се кешира близу до читателите, а подоцнежните преземања на истата непроменета датотека се служат локално. Придобивката е вистинска и тесна: иста содржина, непроменета, повеќе читатели.

Пренослив компјутер што качува ново снимање преку домашна врска е спротивниот случај. Нема претходно кеширана копија на датотека што сè уште не постои, па качувањето оди по истиот ограничен пат како секогаш. Кешот за преземање не отстранува качување и ниеден избор на поставување не го менува тоа.

Третиот облик е тој што ги разочарува луѓето затоа што изгледа како проблем со преземање. Отворањето директориум со десетици илјади датотеки, неговото сортирање и читањето метаподатоци е тек од мали операции, а не повторен пренос на еден голем објект. Кеширањето на телата на датотеките не прави ништо за пописот.

Дистрибуиран кеш: VPN-базен не е LAN на огранок

Во дистрибуиран режим, клиентските компјутери делат кеширана содржина меѓу себе, а Microsoft го документира тој режим како работење во една подмрежа. VPN-базенот на клиенти не е подмрежа во таа смисла, дури и кога сите адреси изгледаат последователни: откривањето на партнери, достапноста клиент-до-клиент и дозволата за размена на кеш-податоци се одделни прашања, а вообичаениот дизајн за оддалечен пристап на сите три одговара со не.

Можете да го направите базенот да се однесува како LAN на огранок со дозволување сообраќај клиент-до-клиент, но тоа е безбедносна одлука, а не кеш-одлука. Повеќето дизајни за оддалечен пристап ги изолираат клиентите еден од друг токму за да не може еден компромитиран пренослив компјутер да стигне до друг, а заменувањето на таа изолација за кеш-погодок е лоша размена, освен ако партнерите веќе не се доверливи рамноправни страни.

За еден постојан патувачки корисник, дистрибуираниот режим нема со кого да дели. Кешот сè уште може да ги служи повторените читања на тој еден клиент, но тоа е придобивка од кеш на клиентска страна, а не придобивка од поставување во огранок, и вреди тоа да се каже пред некој да очекува канцеларијата да стане побрза.

Хостиран кеш: поставувањето одлучува дали помага

Хостираниот кеш го става заедничкиот кеш на сервер, што е единствениот режим што има смисла низ подмрежи и единствениот што работи кога клиентите не можат да разговараат меѓу себе. Непосредното прашање е каде стои тој сервер. Хостиран кеш достапен преку истата ограничена врска како изворот ги преместил бајтите, а не проблемот.

Поставете го близу до читателите, дајте му сопственик и димензионирајте го неговиот диск за работниот сет, а не за целата споделена папка. Microsoft Преглед на BranchCache ги опишува двата режима и однесувањето на клиентот, вклучително делот што луѓето го забораваат: клиентите сè уште контактираат со изворот за авторизација и информации за содржината пред да користат кеширани податоци.

Распоредувањето е три улоги планирани заедно, а не едно поле за избор. Изворниот сервер објавува хешови за содржината, хостираниот кеш е овозможен и може да се открие, а клиентите се конфигурирани да го користат. На серверската страна тоа се препознава во PowerShell:

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

На клиентот, или посочете го кон именувани сервери, или дозволете му да ги открие преку точката за поврзување со услугата; потоа потврдете го режимот што навистина го избрал наместо да претпоставувате дека политиката е применета:

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

Што сè уште стигнува до изворот

Кеширањето не ја отстранува авторизацијата. Клиент без дозвола да чита датотека не добива пристап затоа што некој друг ја кеширал, а изворот сè уште одговара на прашањето за авторизација и ги обезбедува информациите за содржината што го овозможуваат пребарувањето во кешот. Ако изворот е недостапен, само кешираната копија не станува офлајн споделена папка.

Промените во содржината исто така тивко ја кршат претпоставката. Датотека што е повторно зачувана, повторно кодирана или допрена од производ за резервни копии може повеќе да не одговара на кешираниот хеш, а следното читање се враќа на изворот. Тоа е правилно однесување и затоа кешот чиј работен сет се менува на секој час дава малку.

Исфрлањето е третата граница. Кешот е конечен, па голем работен сет исфрла постара содржина, а придобивката зависи од тоа дали повторните читања се случуваат пред исфрлањето, а не по него. Димензионирањето на кешот за целата споделена папка е вообичаениот начин да бидете разочарани од технички правилно распоредување.

Прифатете го со две преземања и едно качување

Тестирајте ги вистинските три текови и запишете што покажува секој. Прво преземање на репрезентативна датотека од клиент, мерено на изворната врска, како и на часовникот на корисникот. Второ преземање на истата непроменета датотека од втор клиент во истата група за поставување. Едно качување на нова датотека, кое треба да не покажува подобрување и го потврдува тоа дека кешот не добива заслуга за нешто што никогаш не го направил.

Ако второто преземање сè уште ја преминува изворната врска за најголемиот дел од бајтите, кешот не се користи, а причината обично е клиент во погрешен режим, отсутно објавување на хеш на изворот или хостиран кеш на погрешната страна од ограничената врска. Тоа се три различни поправки, а само една од нив е за мрежното поставување.

Потоа изразете го заклучокот во истиот облик како првичната поплака: повторените преземања на непроменета содржина од овој извор до овие читатели ги служи овој кеш. Сè друго за споделената папка останува недопрено, вклучително качувањата, пописот на папки и офлајн-приказната, која сè уште бара свој одговор.