Кешування метаданих 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 сховища на слайді — не цей результат.