Кеширање метаподатака у Azure Files наспрам локалног кеша огранка
Кеш метаподатака на страни услуге смањује рад сервера. Не уклања повратна путовања са вашег WAN-а. Упоредите их по томе шта заиста скраћују.
За спор приступ Azure Files преко VPN-а предлажу се две промене и оне скраћују различите ствари. Кеширање метаподатака на страни услуге чини прихватљиве операције јефтинијим за сервер. Локални кеш огранка приближава бајтове и операције кориснику. Бирање између њих према ценовнику или саопштењу за јавност је начин на који дељени ресурс постане бржи на тесту и непромењен у девет ујутру.
Два кеша, две различите латенције
Обе опције се појављују под речју кеш и ту почиње забуна. Оне стоје на супротним странама мреже.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoftове смернице за перформансе SMB-а описују кеширање метаподатака за прихватљива SSD дељења заједно са кораком регистрације који иде уз то. Прихватљивост и стање функције припадају стварном налогу за складиштење, зато читајте тренутну страницу, а не најаву прегледа од пре две године.
Поделите чекање на три дела
Сваки спор списак директоријума има три компоненте трошка и оне реагују на различита решења. Постоји време обраде захтева на страни услуге, број зависних повратних путовања преко VPN-а и садржај који се мора пренети. Кеш на страни услуге напада прво. Ништа на страни сервера не напада друго.
Зато дељени ресурс може показивати боље метрике услуге док се кориснички бирач датотека још увек замрзава на осам секунди.
Где свака опција заслужује своје место
Ако је радно оптерећење тешко на метаподацима, са много отварања, позива stat и набрајања директоријума према прихватљивом SSD дељењу, кеширање на страни услуге је јефтин експеримент. Не тражи нову инфраструктуру и не мења начин на који корисници долазе до дељења.
Ако је радно оптерећење интерактивно и ограничено латенцијом, искрена опција је подржани дизајн локалног сервера са документираним моделом синхронизације. То је друга архитектура са сопственим оперативним трошковима, а не прекидач.
Шта не мења ниједна опција
Потписивање и шифровање SMB-а и даље важе и и даље коштају оно што коштају. Контрола приступа и даље се решава по кориснику, па кеширана копија не поједностављује ауторизацију. Конзистентност између локација и даље тражи дефинисан модел, јер локална читања у огранку и уписи са стране облака морају да се сложе око нечега. А офлајн приступ остаје подешавање клијента, а не нуспојава функције сервера.
Када неко обећа да функција услуге уклања WAN повратна путовања, то је тврдња коју треба прво тестирати.
Мерите према операцији на коју се корисници жале
Измерите тачну операцију, а не синтетичку копију. Measure-Command { Get-ChildItem \\files\projects -Recurse } на клијенту огранка даје број који можете упоредити пре и после, а Get-SmbMultichannelConnection показује користи ли клијент више од једне путање. Ставите то уз метрике латенције на страни услуге за исти период.
Држите дељење, локацију клијента, VPN путању и безбедносну политику константним, иначе мерите свој прозор промена, а не функцију. Забележите и број датотека и расподелу величина, јер радна оптерећења са малим датотекама и масовно копирање реагују на потпуно различите полуге.
Резултат који вреди имати је промена усклађена са границом која је заиста била спора, са уписаним оперативним трошковима и трошковима конзистентности. Већа бројка IOPS складиштења на слајду није тај резултат.