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