Выбор политик по уровням облака

В этой статье приводятся рекомендации по выбору и настройке политик многоуровневого уровня облака для синхронизации файлов Azure. Прежде чем читать эту статью, убедитесь, что вы узнаете, как работает распределение по уровням в облаке. Основные сведения об уровне облака см. в статье "Общие сведения об уровне службы "Синхронизация файлов Azure". Подробное описание политик распределения данных в облаке с примерами см. в разделе "Политики облачного хранения в Azure File Sync".

Ограничения

• Распределение по уровням в облаке не поддерживается в системном томе Windows.

• Если вы используете диспетчер ресурсов файлового сервера (FSRM) для управления квотами на конечных точках сервера, рекомендуется применять квоты на уровне папок, а не на уровне тома. Если у вас есть квота FSRM на уровне томов, можно включить распределение по уровням в облаке. После установки квоты FSRM API-интерфейсы запросов свободного места, которые вызываются автоматически, сообщают о свободном пространстве тома в зависимости от параметра квоты. Однако при наличии жесткой квоты в корне тома фактическое свободное пространство тома и пространство, ограниченное квотой на томе, могут не совпадать. Это может вызвать бесконечный процесс размещения данных на уровнях, если система синхронизации файлов Azure считает, что на конечной точке сервера недостаточно свободного пространства на диске.

Минимальный размер файла для уровня

Минимальный размер файла на уровне зависит от размера кластера файловой системы. Минимальный размер файла, подходящий для распределения по уровням в облаке, вычисляется на 2x размер кластера и не менее 8 КИБ. В следующей таблице показаны минимальные размеры файлов, которые могут быть многоуровневыми на основе размера кластера томов:

Размер кластера томов можно найти, выполнив команду fsutil fsinfo ntfsinfo volumedriveletter: из административной командной строки. Поле "Байт на кластер " отображает размер кластера тома в байтах, а значение в килобайтах отображается в скобках.

Синхронизация файлов Azure поддерживает распределение по уровням облака на томах с размером кластера до 2 МиБ.

Все файловые системы, используемые Windows, упорядочивают жесткий диск на основе размера кластера (также известного как размер единицы выделения). Размер кластера представляет наименьшее количество дискового пространства, которое можно использовать для хранения файла. Если размер файла не выходит на даже несколько размеров кластера, необходимо использовать дополнительное пространство для хранения файла до следующего размера кластера.

Синхронизация файлов Azure поддерживается в томах NTFS с Windows Server 2012 R2 и более поздней версии. В следующей таблице описаны размеры кластеров по умолчанию при создании нового тома NTFS с Windows Server.

Возможно, при создании тома вы вручную отформатировали том с другим размером кластера. Если ваш том связан с более старой версией Windows, размер кластера по умолчанию также может отличаться. Даже если вы выберете размер кластера меньше 4 КиБ, ограничение 8 КиБ в качестве наименьшего размера файла, который может быть многоуровневым, по-прежнему применяется. (Даже если технически 2x размер кластера приравнивается к меньше 8 КиБ.)

Причина абсолютного минимума обусловлена тем, как NTFS хранит очень небольшие файлы - 1 КиБ до 4 КиБ размеров файлов. В зависимости от других параметров тома возможно, что небольшие файлы не хранятся в кластере на диске вообще. Это, возможно, более эффективно для хранения таких файлов непосредственно в главной таблице файлов тома или в записи MFT. Точка повторного распределения по уровням облака всегда хранится на диске и занимает ровно один кластер. Многоуровневое использование таких небольших файлов может привести к тому, что не будет экономии места. Крайние случаи могут даже в конечном итоге использовать больше места с включенным распределением по уровням в облаке. Чтобы обеспечить защиту от этого, при облачном распределении уровней наименьший размер файла, который будет тиражируем, составляет 8 КиБ на кластер размером 4 КиБ или меньше.

Выбор начальных политик

Как правило, при включении облачного тиеринга на серверном конечном узле следует создать один локальный виртуальный диск для каждого серверного конечного узла. Изоляция конечной точки сервера упрощает понимание того, как работает распределение по уровням в облаке, и облегчает соответствующую корректировку политик. Однако синхронизация файлов Azure работает даже в том случае, если на одном диске есть несколько конечных точек сервера, дополнительные сведения см. в разделе "Несколько конечных точек сервера на локальном томе". Мы также рекомендуем, чтобы при первом включении распределения по уровням в облаке политика по дате оставалась отключенной, а политика свободного места на томе устанавливалась на уровне от 10% до 20%. Для большинства томов файлового сервера свободное пространство тома в размере 20% обычно является наилучшим вариантом.

Для упрощения и четкого понимания того, как будет организовано распределение элементов, рекомендуется в первую очередь настроить политику свободного места на томе и оставлять политику даты отключенной, если это не необходимо. Мы рекомендуем это потому, что большинство клиентов считают это ценным для заполнения локального кэша как можно большим количеством часто используемых файлов и остальные переместить в облако. Однако политика дат может быть полезной, если вы хотите заранее освободить локальное место на диске и знаете, что файлы в этой конечной точке сервера, которые были доступны позже, чем число дней, указанное в вашей политике дат, не нужно хранить локально. Настройка политики управления датами освобождает ценное пространство на локальном диске для других конечных точек на том же томе, чтобы кэшировать больше их файлов.

После настройки политик отслеживайте исходящие данные и настраивайте обе политики соответствующим образом. Мы рекомендуем посмотреть метрики размера возврата данных при облачной стратификации и размера возврата данных при облачной стратификации по приложениям в Azure Monitor. Мы также рекомендуем отслеживать частоту попаданий кэша для конечной точки сервера, чтобы определить процент открытых файлов, которые уже находятся в локальном кэше. Сведения о мониторинге исходящего трафика см. в разделе «Мониторинг облачного распределения».

Корректировка ваших политик

Если количество файлов, которые постоянно загружаются из Azure, больше, чем вы хотите, возможно, у вас больше горячих файлов, чем места на локальном сервере для их хранения. Увеличьте размер локального тома, если это возможно, и (или) уменьшите процент политики свободного пространства тома небольшими шагами. Уменьшение процента свободного пространства на дисковом томе слишком сильно также может иметь негативные последствия. Более высокая текучесть данных в вашем наборе требует больше свободного места – для новых файлов и восстановления "холодных" файлов. Включение многоуровневости может происходить с задержкой до одного часа и затем требует времени на обработку, поэтому вы всегда должны иметь достаточно свободного места на вашем диске.

Сохранение более локального хранения данных означает более низкие затраты на исходящий трафик, так как меньше файлов будет загружено из Azure, но также требует большего объема локального хранилища, что само по себе требует затрат.

При настройке политики свободного места тома объем данных, который следует сохранить локально, определяется следующими факторами: пропускной способностью, шаблоном доступа набора данных и бюджетом. При подключении с низкой пропускной способностью может потребоваться больше локальных данных, чтобы обеспечить минимальную задержку для пользователей. В противном случае, вы можете основываться на показателе оттока в течение заданного периода. Например, если вы знаете, что 10% из вашего набора данных объёмом 1 TiB изменяется или активно используется каждый месяц, то вам может понадобиться сохранить 100 ГиБ локально, чтобы вам не приходилось часто вспоминать файлы. Если ваш объем равен 2 ТиБ, то вы захотите сохранить 5% (или 100 ГиБ) локально, что означает, что оставшиеся 95% — это процент свободного места в вашем объеме. Однако следует добавить буфер для периодов большего оттока, иными словами, начать с большего процента объема свободного пространства, а затем настроить его при необходимости позже.

Стандартные операционные процедуры

• При первой миграции в Azure Files с помощью Azure File Sync, облачные уровни зависят от первоначальной загрузки.
• Распределение по уровням в облаке проверяет соответствие политикам свободного пространства и даты тома каждые 60 минут.
• Использование переключателя /LFSM в Robocopy при переносе файлов позволит синхронизировать файлы и освободить место за счет облачного многоуровневого кэширования в процессе начальной загрузки.
• Если переход между уровнями выполняется перед формированием тепловой карты, файлы будут распределены по времени последнего изменения.

Дальнейшие шаги

• Планирование развертывания службы синхронизации файлов Azure