Кеширане на метаданни в 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 |
Ръководството за производителност на SMB от Microsoft описва кеширане на метаданни за допустими SSD споделяния заедно със стъпката за регистрация, която го съпътства. Допустимостта и състоянието на функцията принадлежат на действителния акаунт за съхранение, затова четете текущата страница, а не съобщение за предварителен преглед от преди две години.
Разделете изчакването на три части
Всяко бавно изброяване на директория има три разходни компонента и те реагират на различни поправки. Има време за обработка на заявка от страна на услугата, броят на зависимите обиколки през VPN и полезният товар, който трябва да се пренесе. Кешът от страна на услугата атакува първото. Нищо от страна на сървъра не атакува второто.
Ето защо едно споделяно хранилище може да показва по-добри метрики на услугата, докато изборът на файлове при потребителя все още виси осем секунди.
Къде всяка опция печели мястото си
Ако натоварването е тежко на метаданни, с много отваряния, извиквания на stat и изброявания на директории към допустимо SSD споделяне, кеширането от страна на услугата е евтиният експеримент. То не изисква нова инфраструктура и не променя начина, по който потребителите достигат до споделянето.
Ако натоварването е интерактивно и ограничено от латентност, честният вариант е поддържан дизайн на локален сървър с документиран модел на синхронизация. Това е различна архитектура със собствени текущи разходи, а не превключвател.
Какво не променя нито една от опциите
Подписването и шифроването на SMB продължават да важат и продължават да струват това, което струват. Контролът на достъпа все още се решава за всеки потребител, така че кешираното копие не опростява оторизацията. Съгласуваността между сайтовете все още изисква дефиниран модел, защото четенията в клона и записите от страна на облака трябва да се съгласуват за нещо. А достъпът офлайн остава настройка на клиента, а не страничен ефект от функция на сървъра.
Когато някой обещае, че функция на услугата премахва обиколките през WAN, това е твърдението, което трябва да се провери първо.
Измерете спрямо операцията, за която потребителите се оплакват
Измерете точната операция, а не синтетично копие. Measure-Command { Get-ChildItem \\files\projects -Recurse } на клиент в клона дава число, което можете да сравните преди и след, а Get-SmbMultichannelConnection показва дали клиентът използва повече от един път. Поставете това до метриките за латентност от страна на услугата за същия период.
Държте споделянето, местоположението на клиента, пътя през VPN и политиката за сигурност постоянни, иначе измервате своя прозорец за промени, а не функцията. Записвайте също броя на файловете и разпределението на размерите, защото натоварванията с малки файлове и масовите копия реагират на напълно различни лостове.
Резултатът, който си струва, е промяна, съобразена с границата, която всъщност е била бавна, с записани експлоатационни разходи и разходи за съгласуваност. По-голяма цифра за IOPS на хранилището в слайд не е този резултат.