Выбор политик распределения по уровням в облаке
В этой статье приводятся рекомендации по выбору и настройке политик по уровням облака для Синхронизация файлов Azure. Прежде чем читать эту статью, убедитесь, что вы узнаете, как работает распределение по уровням в облаке. Основные сведения о распределении по уровням в облаке см. в статье Знакомство с распределением по уровням в облаке Синхронизации файлов Azure. Подробное описание политик распределения по уровням в облаке см. в разделе Политики распределения по уровням в облаке Синхронизации файлов Azure .
Ограничения
Распределение по уровням в облаке не поддерживается в системном томе Windows.
Если вы используете диспетчер ресурсов файлового сервера (FSRM) для управления квотами на конечных точках сервера, рекомендуется применять квоты на уровне папок, а не на уровне тома. Вы все же можете включить распределение по уровням в облаке, если у вас есть квота FSRM уровня тома. После того как квота FSRM задана, для API запросов свободного места, которые вызываются автоматически, отображается свободное пространство тома согласно параметру квоты. Однако при наличии жесткой квоты в корневом каталоге тома фактическое свободное пространство тома и ограничение квоты на томе может не совпадать. Это может привести к бесконечному уровню, если Синхронизация файлов Azure считает, что на конечной точке сервера недостаточно свободного места на томе.
Минимальный размер для распределения файла по уровню
Минимальный размер файла на уровне зависит от размера кластера файловой системы. Минимальный размер файла, пригодный для распределения по уровням в облаке, рассчитывается как удвоенный размер кластера, не менее 8 КБ. В следующей таблице приведены минимальные размеры файлов, которые могут быть распределены по уровням в зависимости от размеров кластеров томов.
| Размер кластера тома | Файлы такого размера или больше можно распределять по уровням |
|---|---|
| 4 КиБ или меньше (4096 байт) | 8 КиБ |
| 8 КиБ (8 192 байт) | 16 КиБ |
| 16 КиБ (16 384 байта) | 32 КиБ |
| 32 КиБ (32 768 байт) | 64 КиБ |
| 64 КиБ (65 536 байт) | 128 КиБ |
| 128 КиБ (131 072 байта) | 256 КиБ |
| 256 КиБ (262 144 байта) | 512 КиБ |
| 512 КиБ (524 288 байт) | 1 МиБ |
| 1 MiB (1 048 576 байт) | 2 МиБ |
| 2 МиБ (2 097 152 байта) | 4 МиБ |
Синхронизация файлов Azure поддерживает распределение по уровням в облаке на томах с размером кластера до 2 МиБ.
Все файловые системы, используемые Windows, упорядочивают жесткий диск на основе размера кластера (также известного как размер единицы выделения). Размер кластера представляет минимальный объем дискового пространства, который можно использовать для хранения файла. Если размер файла не выходит на даже несколько размеров кластера, необходимо использовать дополнительное пространство для хранения файла до следующего размера кластера.
Синхронизация файлов Azure поддерживается на томах NTFS с Windows Server 2012 R2 и более поздних версий. В следующей таблице описаны размеры кластера по умолчанию при создании нового тома NTFS с Windows Server 2019.
| Volume size | Windows Server 2019 |
|---|---|
| 7 МиБ…16 ТиБ | 4 Киб |
| 16 МиБ…32 ТиБ | 8 КиБ |
| 32 МиБ…64 ТиБ | 16 КиБ |
Возможно, при создании тома вы вручную отформатируйте том с другим размером кластера. Если ваш том связан с более старой версией Windows, размер кластера по умолчанию также может отличаться. В этой статье содержатся дополнительные сведения о размерах кластера по умолчанию. Даже если вы выберете размер кластера меньше 4 КиБ, ограничение 8 КиБ в качестве наименьшего размера файла, который может быть многоуровневым, по-прежнему применяется. (Даже если технически удвоенный размер кластера будет менее 8 КиБ.)
Причина абсолютного минимума обусловлена тем, как NTFS хранит очень небольшие файлы - 1 КиБ до 4 КиБ размеров файлов. В зависимости от других параметров тома возможно, что небольшие файлы не хранятся в кластере на диске вообще. Возможно, более эффективно хранить такие файлы непосредственно в главной таблице файлов или "записи MFT". Точка повторного анализа распределения по уровням в облаке всегда хранится на диске и занимает ровно один кластер. Распределение таких мелких файлов по уровням может не дать экономии места. В экстремальных случаях включенное распределение по уровням в облаке может привести даже к большим расходам пространства. Чтобы обеспечить защиту от этого, наименьший размер файла, который будет выполняться на уровне облака, составляет 8 КиБ на 4 КиБ или меньший размер кластера.
Выбор начальных политик
Как правило, при включении распределения по уровням в облаке в конечной точке сервера необходимо создать один локальный виртуальный диск для каждой отдельной конечной точки сервера. Изоляция конечной точки сервера упрощает понимание того, как работает распределение по уровням в облаке, и соответствующим образом корректирует политики. Однако Синхронизация файлов Azure работает даже при наличии нескольких конечных точек сервера на одном диске. Дополнительные сведения см. в разделе Несколько конечных точек сервера в локальном томе. Также рекомендуется, чтобы при первом включении распределения по уровням в облаке политика дат была отключена, а политика свободного места тома была установлена на примерно 10–20 %. Для большинства томов файлового сервера обычно лучшим вариантом является 20% свободного места на томе.
Для простоты и четкого понимания того, как будут распределяться элементы, мы рекомендуем скорректировать политику свободного места тома и отключать политику дат, когда она не требуется. Мы рекомендуем делать так потому, что большинство клиентов сочтут полезным заполнять локальный кэш максимально возможным количеством активных файлов и распределять все прочее по уровням в облаке. Однако политика дат может оказаться полезной, если вы хотите заранее освобождать место на локальном диске и уверены, что файлы в этой конечной точке сервера, доступ к которым выполняется по прошествии количества дней, указанных в политике дат, не нужно хранить локально. При установке политики даты освобождается ценная емкость локального диска для других конечных точек на том же томе, позволяя кэшировать больше файлов.
После настройки политик следует отслеживать исходящий трафик и корректировать обе политики соответствующим образом. Мы рекомендуем ознакомиться с размером отзыва по уровням в облаке и размером отзыва по уровням в облаке по метрикам приложений в Azure Monitor. Мы также рекомендуем отслеживать частоту попаданий кэша для конечной точки сервера, чтобы определить процент открытых файлов, которые уже находятся в локальном кэше. Сведения о мониторинге исходящего трафика см. в разделе Мониторинг распределения по уровням в облаке.
Настройка политик
Если количество файлов, постоянно отозванных из Azure, больше, чем нужно, может быть более горячих файлов, чем у вас есть место, чтобы сохранить их на томе локального сервера. Увеличьте размер локального тома, если это возможно, и (или) малыми шагами уменьшите процент политики свободного места на томе. Чрезмерное уменьшение объема свободного места в томе может также может вызвать негативные последствия. Более высокий уровень обновления в наборе данных требует больше свободного пространства — для новых файлов и для отзыва "холодных" файлов. Распределение по уровням начинается с задержкой до одного часа, а затем требует времени для обработки, поэтому следует всегда иметь достаточно свободного места на томе.
Сохранение более локальных данных означает более низкие затраты на исходящий трафик, так как меньше файлов будет отозвано из Azure, но также требует большего объема локального хранилища, которое приходится по своей собственной стоимости.
При настройке политики свободного места на томе объем данных, которые должны оставаться локальными, определяется следующими факторами: пропускная способность, шаблон доступа к набору данных и бюджет. При низкой пропускной способности подключения может быть необходимо больше локальных данных, чтобы гарантировать минимальный лаг для пользователей. В противном случае можно учитывать частоту изменения данных в рамках определенного периода. Например, если вы знаете, что 10% из 1 тиБ-наборов данных изменяется или активно обращается каждый месяц, то может потребоваться сохранить 100 ГиБ локально, чтобы вы не часто вспоминали файлы. Если объем равен 2 ТиБ, то вы хотите сохранить 5 % (или 100 ГиБ), то есть оставшееся 95 % — это процент свободного места на томе. Однако следует добавить буфер для периодов более высокого объема оттока, иными словами, начать с большего процента свободного места в томе, а затем настроить его при необходимости позже.
Стандартные рабочие процедуры
- При первоначальной миграции в Файлы Azure через Синхронизацию файлов Azure распределение по уровням в облаке зависит от начальной передачи
- Распределение по уровням в облаке проверяет соответствие политикам свободного места и доступности тома каждые 60 минут.
- Использование параметра /LFSM в Robocopy при миграции файлов позволит синхронизировать файлы и распределять по уровням в облаке, чтобы освободить место во время начальной передачи.
- Если распределение по уровням выполняется до формирования тепловой карты, файлы будут распределены по времени последнего изменения.