Кеширање метаподатоци во 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 на складиштето на слајд не е тој резултат.