Заметки о Windows и других программных продуктах Microsoft...

Дедупликация данных в Windows Server 2016 (часть 2)

Дедупликация данных в Windows Server 2016 (часть 2)

Продолжаем разговор о дедупликации данных в Windows Server 2016, начатый в предыдущей статье. Сегодня речь пойдет о тонких настройках, особенностях работы дедупликации и проблемах, с которыми можно столкнуться в процессе ее использования.

Задания дедупликации

Дедупликация состоит из трех этапов, которые выполняются в виде запланированных заданий:

• Оптимизация (Optimization) — в процессе оптимизации файлы разбиваются на блоки (chunk), вычисляются совпадающие блоки и лишние копии блока удаляются, заменяясь ссылками. Затем из блоков формируются контейнеры, которые в зависимости от настроек, дополнительно сжимаются и помещаются в хранилище блоков (chunk store);
• Сборка мусора (Garbage Collection) — удаление блоков данных, на которые нет активных ссылок. При удалении оптимизированного файла относящиеся к нему блоки не удаляются из хранилища немедленно. Задание сборки мусора находит эти ″бесхозные″ блоки и удаляет их, тем самым освобождая дисковое пространство;
• Очистка (Scrubbing) —  проверка целостности дедуплицированных данных. Используется для анализа повреждений хранилища и, по возможности, для восстановления поврежденных данных.

Список всех запланированных заданий можно вывести командой Get-DedupSchedule.

список заданий дедупликации

 

Задания сборки мусора и очистки дополнительно разделяются на обычные и полные (full):

Полная сборка мусора

При обычной сборке мусора контейнер хранилища блоков сжимается только в том случае, если  существует минимальный процент блоков без ссылок. При полной сборке мусора контейнер сжимается даже в том случае, если на отдельный блок в контейнере отсутствует ссылка. Также при полной сборке освобождается место, которое могло быть использовано при нештатном завершении работы дедупликации (напр. при сбое питания). Обычный тип сборки мусора работает быстрее и потребляет меньше ресурсов, чем полный, но освобождает меньше места. Полная сборка мусора освобождает до 5% больше места, чем обычная, но при этом работает дольше и потребляет большее количество системных ресурсов. По умолчанию каждая 4-я процедура сборки мусора является полной.

Полная очистка

Обычная очистка проверяет и исправляет только целостность критических метаданных и данных, для которых ранее были зафиксированы проблемы. При полной очистке проверке подвергаются все без исключения данные на томе. Этот тип очистки нет необходимости запускать часто, поэтому по умолчанию он не используется. Запустить его можно вручную, с помощью командлета Start-DedupJob с ключом Full.

Задания оптимизации также подразделяются на три типа:

Фоновая оптимизация (Background optimization)

Задание дедупликации запускается каждый час и работает с низким приоритетом, потребляя минимальное количество ресурсов. Подобный режим запуска позволяет максимально экономить ресурсы сервера и выполнять оптимизацию только при отсутствии нагрузки. Если ресурсы  для выполнения задания оптимизации станет недостаточно без влияния на рабочую нагрузку сервера, то задание будет остановлено.

фоновая оптимизация

 

Приоритетная оптимизация (Priority optimization)

Также запускается раз в час, но работает с нормальным приоритетом и потребляет большее количество системных ресурсов (до 50% памяти и до 100% процессора). В файлах большого размера при фрагментации количество фрагментов может приближаться к пороговому значению для одного файла. При оптимизации происходит объединение фрагментов. Включение приоритетной оптимизации добавляет дополнительные процедуры обработки, что позволяет уменьшить уровень фрагментации. Данный тип оптимизации Microsoft рекомендует для виртуальных серверов резервного копирования.

приоритетная оптимизация

 

Производительная оптимизация (Throughput optimization)

Самый простой и понятный 🙂 тип задания, который запускается по расписанию в указанное время, с указанными параметрами и работает с нормальным приоритетом. По умолчанию задания производительной оптимизации не включены ни для одного типа нагрузки, они создаются по необходимости, например в дополнение к фоновой оптимизации. При желании можно создать несколько заданий, которые будут отрабатывать в разные дни недели с разными настройками.

производительная оптимизация

Настройка заданий дедупликации

Ну уровне заданий находится довольно много важных параметров. Параметры эти задаются либо при создании задания командлетом New-DedupSchedule, либо при его редактировании командлетом Set-DedupSchedule. Давайте рассмотрим некоторые из этих параметров:

• Type — тип задания, может принимать одно из трех значений (Optimization, GarbageCollection или Scrubbing);
• Days — дни недели, на которые запланирован запуск задания;
• Start — время запуска задания;
• DurationHours — максимально допустимое время выполнения задания. По истечении этого времени задание будет остановлено в принудительном порядке, независимо от того, отработало ли оно полностью или нет;
• Memory — максимальный объем оперативной памяти, доступный для задания. Задается в процентах от общего объема памяти в системе;
• Cores — количество ядер процессора (физических или логических, если используется HyperThreading), доступных для  выполнения задания. Задается в процентном соотношении от общего количества ядер в системе;
• Priority — системный приоритет, с которым будет запущено задание. Можно указать низкий (low), средний (normal) или высокий (high) приоритет. В зависимости от приоритета производится распределение процессорной мощности в системе — чем выше приоритет, тем больше процессорного времени получит процесс;
• StopWhenSystemBusy — указывает, что дедупликация должна выполняться только при наличии в системе свободных ресурсов. Если же система занята и свободных ресурсов нет, дедупликация должна быть остановлена. С помощью этого параметра можно уменьшить влияние дедупликации на работу сервера в тех случаях, когда она выполняется параллельно с другими нагрузками;
• InputOutputThrottle — уровень ограничения операций ввода\вывода для задания, число от 0 до 100. Позволяет уменьшить влияние дедупликации на другие нагрузки;
• InputOutputThrottleLevel — параметр, аналогичный предыдущему. Также служит для регулирования операций ввода\вывода, может принимать значения Low, Normal или High. Если оба параметра используются совместно, то InputOutputThrottle имеет больший приоритет;
• Full — применяется к заданиям сборки мусора и очистки, определяет, будет ли задание полным или обычным. Может принимать значение $true или $false;
• ReadOnly — применяется к заданиям очистки. При запуске очистки в этом режиме выводится информация поврежденных данных, но не предпринимаются действия по их исправлению.

Для наглядности несколько примеров. Сначала создадим новое запланированное задание:

New-DedupSchedule -Name ThroughputOptimization -Type Optimization

Как видите, для нового задания достаточно указать его имя и тип — единственные обязательные параметры. В этом случае будет создано ежедневное задание со стандартными параметрами.

задание оптимизации с дефолтными параметрами

 

Обозвать задание можно как угодно, но тут есть интересный момент.  Для заданий производительной оптимизации существуют два предопределенных имени: ThroughputOptimization и ThroughputOptimization-2. Эти имена даются заданиям в том случае, если их настраивать их оснастки Server Manager. И если при создании нового задания оптимизации из PowerShell указать одно из этих имен, то задание будет отображаться и в графической оснастке.

это же задание в графической оснастке

 

Стандартное расписание может подходить не всем, поэтому изменим его:

Set-DedupSchedule -Name ThroughputOptimization -Days @(1,2,3,4,5) -DurationHours 24 -Start ″8:00 PM″

Дни недели можно указывать по именам через запятую (Sunday, Monday) либо по номерам, в виде массива чисел от 0 (воскресенье) до 6 (суббота). Значение @(1,2,3,4,5) означает запуск задания с понедельника по пятницу.

С параметром DurationHours есть некоторые непонятки. При выставлении его через графическую оснастку максимальное значение составляет 24 часа, при настройке через PowerShell ограничение составляет 100 часов, а из планировщика — максимум 72 часа (з дня). Эти же 3 дня устанавливаются при создании задания из PowerShell без указания данного параметра.

Параметр Start представляет из себя значение в формате System.DateTime. Указывать его можно также по разному, напр. 8:00 PM означает старт в 8 часов вечера начиная с текущего дня. Можно указать и дату полностью, напр. Get-Date ″12/8/2016 8:00 PM″.  При этом сама дата не особо важна (если она указана в прошлом), а вот часть с временем как раз указывает на время запуска задания. Также при указании даты надо учитывать внимание на формат времени, использующийся на сервере.

Ну и в завершение можно подкорректировать параметры производительности для задания, скажем для уменьшения влияния дедупликации на работу сервера:

Set-DedupSchedule -Name ThroughputOptimization -Memory 25 -Cores 75 -Priority Low -InputOutputThrottle 20 -StopWhenSystemBusy $true

В результате получаем

редактирование задания

 

Все задания дедупликации можно увидеть в планировщике  (Task scheduler), в разделе Microsoft\Windows\Deduplication.

задания дедупликации в планировщике

 

Там также можно настраивать расписание заданий. Более того, некоторые параметры можно изменить только с помощью планировщика. Например задания приоритетной и фоновой оптимизации запускается в момент включения дедупликации для тома, после чего отрабатывают каждый час в течении неограниченного времени. Эти настройки нельзя увидеть\изменить с помощью средств управления дедупликацией, они доступны только в планировщике.

настройки приоритетной оптимизации

 

Также планировщик позволяет более гибко управлять расписанием дедупликации. С его помощью можно составить не еженедельное, а ежемесячное расписание, например каждое второе воскресенье месяца.

ежемесячное расписание дедупликации

 

Однако при настройке ежемесячного расписания здание пропадет из списка и его будет невозможно отредактировать. Для редактирования придется сначала вернуться к стандартному расписанию.

ошибка при доступе к заданию

Настройка дедупликации для тома

Некоторые параметры настраиваются на уровне тома. Просмотреть их можно с помощью командлета Get-DedupVolume. Например:

Get-DedupVolume D: | fl

свойства тома

 

Помимо прочего эта команда выводит некоторые важные настройки, которые могут влиять на производительность дедупликации:

• MinimumFileAgeDays — возраст файла, по достижении которого файл считается пригодным для оптимизации. По умолчанию для файловых серверов и виртуальных машин Hyper-V этот параметр равен 3, т.е. файлы младше 3 дней не подвергаются оптимизации. Уменьшение этого значения способно повысить эффективность дедупликации, однако это может отрицательно сказаться на производительности системы;
• MinimumFileSize — минимальный размер файла, который считается пригодным для оптимизации. По умолчанию файлы размером меньше 32кб не оптимизируются, поскольку их оптимизация не приносит ощутимой экономии дискового пространства;
• NoCompress — параметр указывает, следует ли сжимать блоки перед их помещением в хранилище. По умолчанию сжатие включено, но в некоторых случаях, например при оптимизации уже сжатых данных (напр. архивы) сжатие можно отключить. Это позволит снизить нагрузку, создаваемую дедупликацией;
• NoCompressionFileType — типы файлов, блоки которых не надо сжимать перед помещением в хранилище. Этот параметр представляет собой массив расширений файлов. Если предыдущий параметр выключает сжатие для всего тома, то здесь мы прицельно можем задать типы файлов, которые нет необходимости сжимать, например аудио\видео-файлы или сжатые архивы. Некоторые из них уже включены в массив по умолчанию;
• OptimizeInUseFiles — определяет, можно ли считать доступными для оптимизации открытые файлы. Этот параметр должен быть включен при дедупликации файлов, которые остаются открытыми длительное время, таких как VHD-диски работающих виртуальных машин или файлы баз данных. Без него такие файлы не будут оптимизированы;
• OptimizePartialFiles — оптимизация файлов по частям. При включении этого параметра при оптимизации параметр MinimumFileAgeDays применяется не ко всему файлу, а к его отдельным сегментам. Этот параметр должен быть включен в том случае, если оптимизация применяется к большим, постоянно изменяющимся файлам, в которых изменяется только небольшая часть, а большая часть файла остается без изменений;
• InputOutpitScale — задает уровень параллелизации операций ввода\вывода в процессе оптимизации тома. Допустимые значения от 0 до 36. При значении 0 (значение по умолчанию) система автоматически определяет уровень параллелизации в зависимости от размера тома. Этот параметр новый, он появился в Windows Server 2016 и отвечает за ограничение количества очередей ввода\вывода при обработке данных. Перед его изменением стоит хорошо подумать, так как неоптимальное значение может очень сильно уменьшить скорость работы дедупликации;
• Verify — отвечает за дополнительную проверку целостности. При включении этого параметра если хэш блока соответствует блоку, уже имеющемуся в хранилище, блоки сравниваются побайтно. Теоретически это должно исключить ошибку при совпадении хэша у двух разных блоков, на практике же такая ситуация крайне маловероятна. Кроме того, включение функции проверки существенно повышает нагрузку на систему;
• ChunkRedundancyTreshold — количество ссылок на блок данных, при достижении которого блок необходимо продублировать в разделе активной зоны хранилища. Таким образом ускоряется доступ к блокам, на которые часто ссылаются. По умолчанию этот параметр равен 100 и без крайней необходимости его лучше не менять, так как это может понизить эффективность дедупликации.

Изменить параметры дедупликации для тома можно с помощью командлета Set-DedupVolume. Для примера уменьшим минимальный возраст файла до нуля и отключим частичную дедупликацию файлов для тома:

Set-DedupVolume -Volume D: -MinimumFileAgeDays 0 -OptimizePartialFiles:$false

настройка параметров дедупликации для тома

Типы дедупликации

Теперь плавно переходим к выбору типа дедупликации. Тип дедупликации представляет собой готовый набор настроек, оптимизированный под определенную рабочую нагрузку. Это позволяет не заморачиваться с подбором параметров, а просто выбрать подходящий тип дедупликации. В Windows Server 2016 на выбор предлагается 3 типа:

Default

Этот тип предназначен для файловых серверов общего назначения. Для него включена фоновая оптимизация  и используются следующие настройки:

• MinimumFileAgeDays — 3 дня;
• OptimizeInUseFiles — $false;
• OptimizePartialFiles — $false.

HyperV

Этот тип применяется для дедупликации виртуальных машин Hyper-V. Для него кроме фоновой включена приоритетная оптимизация и используются следующие настройки:

• MinimumFileAgeDays — 3 дня;
• OptimizeInUseFiles — $true;
• OptimizePartialFiles — $true.

Backup

Тип дедупликации, специально предназначенный для виртуализованных серверов резервного копирования, таких как Microsoft Data Protection Manager. Для этого типа также по умолчанию включена фоновая и приоритетная оптимизация, настройки следующие:

• MinimumFileAgeDays — 0 дней;
• OptimizeInUseFiles — $true;
• OptimizePartialFiles — $false.

Примечание. В документации Microsoft упоминается о дополнительных тонких настройках, которые применяются для каждого конкретного типа использования. Возможно эти настройки скрыты от пользователя, так как при сравнении различных типов дедупликации я не нашел существенных различий, кроме описанных выше.

Настройки операционной системы

Некоторые настройки можно изменить на уровне операционной системы, с помощью реестра. Настройки дедупликации можно найти в разделе HKLM\System\CurrentControlSet\Services\ddpsvc\Settings для одиночного сервера или в HKLM\Cluster\Dedup для кластера. Эти параметры применяются ко всем без исключения томам и заданиям дедупликации, выполняющимся в системе.

К примеру, для настройки интервала запуска задания полной сборки мусора можно добавить параметр DWORD с именем DeepGCInterval такой командой:

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\ddpsvc\Settings -Name DeepGCInterval -Type Dword -Value 0

Значение этого параметра задает интервал запуска полной сборки мусора, т.е. каждое N-е задание является заданием полной сборки мусора. По умолчанию полная сборка мусора запускается каждое четвертое задание, но иногда это требуется изменить, например увеличить этот интервал. А если задать параметру значение 0, то полная сборка мусора будет совсем отключена.

Для исправления ситуации, когда задание дедупликации отменяется с ошибкой «uses too much memory» можно добавить параметр DWORD с именем WlmMemoryOverPercentThreshold, например:

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\ddpsvc\Settings -Name WlmMemoryOverPercentThreshold -Type Dword -Value 300

Значение параметра означает, насколько задание дедупликации может увеличить установленный по памяти лимит. Например, значение 300 означает, что что можно превысить лимит в 3 раза (на 300%).

При очень высоком уровне сжатия (saving rate>80%) задания оптимизации могут отрабатывать медленнее из за того, что требуется выделять больше памяти для обработки сжатия. Для корректировки объема памяти можно добавить параметр EstimatedCompressionRate такой командой:

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\ddpsvc\Settings -Name EstimatedCompressionRate -Value 5

Значение параметра устанавливается в диапазоне от 5 до 10, в зависимости от уровня сжатия. Для сверх-высокого уровня сжатия (90%-95%) рекомендуется значение 10.

Настройки файловой системы

В некоторых случаях для корректной работы дедупликации может потребоваться специальным образом подготовить файловую систему. Так при использовании больших (1ТБ и более) файлов рекомендуется задать размер кластера 64кб, а также увеличить размер сегмента записи файла (File Record Segment, FRS) до 4кб.

По умолчанию размер кластера NTFS составляет 4кб, а размер FRS — 1кб. Проверить эти значения можно с помощью утилиты fsutil, командой:

fsutil fsinfo ntfsinfo D:

свойства тома

 

Для изменения этих параметров потребуется переформатировать том. Сделать это можно из командной строки:

format D: /A:64K /L /Q

Либо с помощью PowerShell:

Format-Volume -Partition D: -FileSystem NTFS -AllocationUnitSize 64KB -UseLargeFRS -Force

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

Мониторинг и проверка состояния

Для просмотра и анализа я предпочитаю использовать командлеты Get-DedupStatus или Update-DedupStatus, которые показывают все основные данные о состоянии тома — сэкономленное место, уровень сжатия, количество оптимизированных файлов и т.п.

Примечание. Оба командлета выводят одинаковый набор данных, но между ними есть одно отличие. Get-DedupStatus показывает закешированные данные, тогда как Update-DedupStatus перед выводом производит сканирование тома на предмет изменений.

Кроме того, они выводят данные о времени запуска и результате выполнения заданий дедупликации. В случае проблем с дедупликацией эта информация поможет найти причину. Так в нашем примере можно увидеть, что последнее задание сборки мусора не смогло отработать до конца и было отменено.

состояние дедупликации

 

Более подробную информацию можно найти в системном журнале, в разделе «Application and Services Log\Microsoft\Windows\Deduplication». Как видите, в нашем случае задание было отменено вручную.

журнал событий дедупликации

 

Ну и для расширенного анализа можно использовать данные, выдаваемые командлетом Get-DedupMetadata. Он возвращает подробные данные о состоянии хранилища дедуплицированных данных:

• TotalChunkStoreSize — размер хранилища блоков;
• DataChunkCount — число блоков данных на томе;
• DataChunkAverageSize — средний размер блока. Вычисляется как размер хранилища, деленный на общее число блоков;
• DataContainerCount — число контейнеров в хранилище;
• HotspotCount — число блоков в активной зоне.  В активную зону попадают блоки, на которые часто ссылаются (по умолчанию более 100 раз). Все блоки в активной зоне дублируются, чтобы обеспечить более быстрый доступ и автоматическое восстановление в случае их повреждения;
• HotspotContainerCount — число контейнеров в активной зоне;
• CorruptionsCount — число поврежденных элементов, найденных на томе;
• CorruptionsLogEntryCount — число записей о поврежденных элементах на томе. Чем отличаются два этих параметра я так и не выяснил;
• StreamMapCount — число схем потоков данных на томе. Насколько я понимаю, под схемой потока понимается набор метаданных, определяющих расположение блоков с данным;
• StreamMapChunkCount — число блоков в хранилище схем потоков;
• StreamMapContainerCount — число контейнеров в хранилище схем потоков.

Так в нашем примере общий размер хранилища составляет около 33.5Гб. Дедупликации подверглись 501758 блоков, средний размер блока составляет примерно 70кб.

метаданные дедупликации

Заключение

В заключение опишу некоторые проблемы, с которыми можно столкнуться при использовании дедупликации.

Нагрузка

При использовании дедупликации надо понимать, что процедура эта требует достаточно много вычислительных ресурсов процессора, памяти и дисковых операций. Особенно требовательна дедупликация к оперативной памяти, для обработки 1Тб данных требуется примерно 2Гб памяти. Конечно эта цифра примерная и зависит от множества факторов — типа нагрузки, частоты изменения данных и т.п.

При нехватке ресурсов дедупликация начинает работать медленно и неэффективно (увеличивается время выполнения, уменьшается уровень сжатия) и даже может полностью остановиться.  С другой стороны, дедупликацию все же необходимо ограничивать, так как в противном случае она может выбрать все свободные ресурсы и ″положить″ сервер. Говорю это по собственному опыту.

Расписание

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

Второй момент, связанный с расписанием — это необходимость регулярного запуска задач сборки мусора и очистки. Проблема в том, что все задания выполняются по очереди, и если на момент запуска одного задания выполняется другое, то новое задание ставится в очередь и через некоторое время отменяется. В результате задания сборки и очистки могут не выполняться в течение длительного времени, что приводит к печальным последствиям.

При отсутствии регулярной сборки мусора увеличивается занимаемое место, а без очистки возможно повреждение и потеря данных. Поэтому желательно составить расписание таким образом, чтобы на момент их запуска в системе не было запущенных заданий дедупликации.

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

На этом все.  Для тех, кто не знаком с дедупликацией, я рекомендую посмотреть вот эту статью, где описан принцип ее работы и основные понятия. Статья написана еще для Windows Server 2012, но основные моменты остались неизменными до сих пор. Также на технете есть ряд статей по дедупликации в Windows Server 2016.

 
 
Комментарии

Пока нет комментариев.