BranchCache foar bestandsmappen oer VPN: wannear't it helpt, wannear't net
BranchCache fersnelt werhelle downloads fan ûnferoare ynhâld, net uploads of mapkeamerlistings. Kontrolearje earst de pleatsing, berikberens en de klintmodus.
Immen yn it team seit dat de bestandsmappe oer de VPN stadich is, en it earste advys is altyd in cache. Foar't jo BranchCache tafoegje oan it ûntwerp foar tagong op ôfstân, diel de klacht op yn ien fan trije foarmen: werhelle downloads fan ûnferoare ynhâld, uploads, of metadata-swier sneupen troch mappen mei tûzenen items. BranchCache lost de earste foarm op stipe ynhâld op en docht neat nuttich foar de oare twa. Dat is gjin beheining om om hinne te wurkjen; it is de ferliking dy't jo meitsje moatte foar't jo in wike oan útrôlje besteegje.
Deselde map, trije ferskillende klachten
In filiaal dêr't acht minsken deselde ûnferoare treningsfideo iepenje, is it gefal dêr't de funksje foar ûntwurpen is. De earste ophaal giet oer de WAN, de ynhâld wurdt tichtby de lêzers cachet, en lettere ophalen fan deselde ûnferoare triem wurde lokaal tsjinne. It foardiel is echt en smel: deselde ynhâld, ûnferoare, meardere lêzers.
In laptop dy't in nije opname uploadt fia in thúsferbining is it tsjinoerstelde gefal. Der is gjin earder cachet kopy fan in triem dy't noch net bestiet, dus folget de upload itselde beheinde paad as altyd. In downloadcache hellet in upload net fuort, en gjin inkelde pleatsingskar feroaret dat.
De tredde foarm is dejinge dy't minsken teloarstelt, om't it op in downloadprobleem liket. In map iepenje mei tsientûzenen triemen, sorteare en metadata lêze is in stream fan lytse bewurkingen, net in werhelle oerdracht fan ien grut objekt. It cachejen fan de lichems fan triemen docht neat foar de listlisting.
Ferspraat cache: in VPN-pool is gjin filiaal-LAN
Yn ferspraat modus diele klintkompjûters cachete ynhâld mei elkoar, en Microsoft dokumintearret dy modus as wurkjend binnen ien subnet. In VPN-pool fan klinten is yn dy betsjutting gjin subnet, sels as alle adressen oanelkoar lykje: it finen fan peers, berikberens fan klint nei klint en tastimming om cachedata út te wikseljen binne aparte fragen, en it gewoane ûntwerp foar tagong op ôfstân antwurdet op alle trije mei nee.
Jo kinne de pool har as in filiaal-LAN gedrage litte troch ferkear tusken klinten ta te stean, mar dat is in feilichheidsbeslút, gjin cachebeslút. De measte ûntwerpen foar tagong op ôfstân isolearje klinten fan elkoar krekt sadat ien kompromittearre laptop in oaren net berikke kin, en dat isolearjen ruilje foar in cachehit is in minne ruil, útsein as de peers al fertroude gelikense binne.
Foar ien rûnreizgjende brûker hat de fersprate modus nimmen om mei te dielen. De cache kin noch hieltyd de werhelle lêzingen fan dy iene klint tsjinje, mar dat is in foardiel fan cache oan klintkant, gjin foardiel fan filiaampleatsing, en it is de muoite wurdich om dat te sizzen foar't immen ferwachtet dat it kantoar flugger wurdt.
Hostede cache: pleatsing beslút oft it helpt
In hostede cache set de dielde cache op in server, dat is de iennichste modus dy't sin hat tusken subnetten en de iennichste dy't wurket as klinten net mei elkoar prate kinne. De direkte fraach is wêr't dy server stiet. In hostede cache dy't berikt wurdt oer deselde beheinde keppeling as de oarsprong hat de bytes ferplakt, net it probleem.
Pleatsearje it tichtby de lêzers, jouw it in eigner, en mjit de skiif foar de wurkset yn stee fan foar de hiele map. De oersjoch fan BranchCache fan Microsoft beskriuwt beide modi en it gedrach fan de klint, ynklusyf it part dat minsken ferjitte: klinten nimme noch hieltyd kontakt op mei de oarsprong foar autorisaasje en ynhâldynformaasje foar't se cachete data brûke.
Útrôlje is trije rollen dy't tegearre pland wurde, net ien kontrôlefak. De boarneserver publisearret hashes foar de ynhâld, de hostede cache is ynskeakele en te finen, en de klinten binne ynsteld om it te brûken. Oan de serverkant is dat werkenber yn PowerShell:
Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList
Op de klint kinne jo it nei neamde servers wize of it troch it tsjinstferbiningspunt fine litte; befêstigje dan de modus dy't it eins keas yn stee fan oan te nimmen dat it belied tapast is:
Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode
Wat noch hieltyd de oarsprong berikt
Cachejen hellet autorisaasje net fuort. In klint sûnder tastimming om in triem te lêzen krijt gjin tagong om't in oaren dy cachet hat, en de oarsprong beantwurdet noch hieltyd de autorisaasjefraach en leveret de ynhâldynformaasje dy't de syktocht yn 'e cache mooglik makket. As de oarsprong net berikber is, wurdt it cachete kopy allinnich gjin offline-map.
Feroarings yn ynhâld brekke de oanname ek stil. In triem dy't wer bewarre, wer koadeare of troch in reservekopyprodukt oanrekke is, kin net mear by de cachete hash passe, en de folgjende lêzing giet werom nei de oarsprong. Dat is korrekt gedrach, en dêrom jout in cache dy't elke oere feroaret min.
It fuortstjitten is de tredde beheining. De cache is einich, dus in grutte wurkset stjit âldere ynhâld fuort, en it foardiel hinget ôf fan oft werlêzingen foar it fuortstjitten barre, net dêrnei. De cache foar de hiele map mjitse is de gewoane manier om teloarsteld te wurden troch in útrol dy't technysk korrekt wie.
Akseptearje it mei twa ophaal en ien upload
Test de trije goede streamen en skriuw op wat elk sjen lit. Earste ophaal fan in represintatyf triem fan in klint, metten op 'e keppeling fan 'e oarsprong en ek op 'e klok fan 'e brûker. Twadde ophaal fan deselde ûnferoare triem fan in twadde klint yn deselde pleatsingsgroep. Ien upload fan in nije triem, dy't gjin ferbettering sjen litte moat en befêstiget dat de cache gjin kredyt krijt foar eat dat er nea die.
As it twadde ophaal noch hieltyd de keppeling fan 'e oarsprong krúst foar it meastepart fan 'e bytes, wurdt de cache net brûkt, en de oarsaak is meastentiids in klint yn 'e ferkearde modus, in ûntbrekkende hashpublikaasje op 'e oarsprong, of in hostede cache oan 'e ferkearde kant fan 'e beheinde keppeling. Dat binne trije ferskillende reparaasjes, en mar ien giet oer netwurkpleatsing.
Bring dan de konklúzje yn deselde foarm as de oarspronklike klacht: werhelle downloads fan ûnferoare ynhâld fan dizze oarsprong nei dizze lêzers wurde troch dizze cache tsjinnet. Al it oare oer de map bliuwt ûnoanrekke, ynklusyf uploads, maplistlisting en it offlineferhaal, dat noch hieltyd syn eigen antwurd nedich hat.