Словил глюки дедупликации в Server 2012R2 + Hyper-V - похоже, не очищалось chunk store.
Вчера встретил глюк дедупликации MS и Hyper-V, связанный с неосвобождением свободного места.
Есть файл-сервер (2012r2), на котором на локальных дисках (физических) есть раздел (d:) и на нем поднята шара. В шаре лежат тестовые виртуалки Hyper-V (их диски, конфигурация и своп), с которыми работает файловер кластер из двух узлов, и в оперативной и на процессорах которого виртуалки и выполняются. Именно файловая шара, а не общий для кластера диск, используется по нескольким причинам - так удобнее мигрировать виртуалки с 2012 на 2012r2 без остановки виртуалок, кластер всё равно тестовый и еще одной физической хранилки не было.
Разные виртуалки мигрировали на этот кластер и хранилку и с него. Иногда после миграции (всё через live migration, не выключая) файлы виртуалок не удалялись, т.к. были заняты пользователем system. Разблокировка и удаление файлов уже несуществующей виртуалки происходило после рестарта ноды кластера, на которой жила эта виртуалка, или поочередного рестарта обеих нод.
Постепенно начали накапливаться необъяснимые глюки - место на диске (1.5 Тб, свободно было около 300 Гб) стало кончаться, при том что файлов виртуалок было явно не на столько много (а уж как оно это в GUI показывает - просто песня!), информация о свободном месте стала обновляться только после рестарта сервера, и, наконец, эффективность дедупликации стала стабильно 0%, при том что Get-DedupMetadata d: выдавало данные о работающей дедупликации:
Volume : D:
VolumeId : \\?\Volume{4ebd6280-55a5-4d4e-8284-a3e8448c09e5}\
StoreId : {21C34345-7466-4A88-8B23-280E5D51A6F7}
DataChunkCount : 29517961
DataContainerCount : 881
DataChunkAverageSize : 31.18 KB
DataChunkMedianSize : 0 B
DataStoreUncompactedFreespace : 0 B
StreamMapChunkCount : 174483
StreamMapContainerCount : 2791
StreamMapAverageDataChunkCount :
StreamMapMedianDataChunkCount :
StreamMapMaxDataChunkCount :
HotspotChunkCount : 309107
HotspotContainerCount : 9
HotspotMedianReferenceCount :
CorruptionLogEntryCount : 0
TotalChunkStoreSize : 1.05 TB
Включение и выключение дедупликации, рестарт сервера, чекдиск и т.п. не помогали. Помогла похоже только полная де-дедупликация диска, командой Start-DedupJob -type unoptimization -volume d: -preempt (результаты Get-DedupJob), при этом свободное место уменьшилось c ~300 до ~100Гб, а после завершения процедуры стало ~750Гб. Get-DedupMetadata d: больше ничего не выдает, а выдает теперь ошибку, т.е. дедупликация полностью выключена. Chkdsk никаких проблем ни до, ни после не находил. Вывод - вероятно, какие-то цепочки в chunk store оказались заблокированы hyper-v и из-за каких-то глюков не очистились, оставшись "потерянными кластерами", причем chkdsk на это не обратил внимание - для него это просто файлы.
Попробую вот сейчас включить назад и понаблюдать, процедура ремонта теперь понятна. На соседнем тестовом кластере (2.5 Тб хранилище, свободно 1.2 Тб , 30 небольших виртуалок под разной виндой) экономия от дедупликации 54% или 1.47 Тб, так что оно того стоит. Только разжать назад если что можно уже только с переносом виртуалок.
UPD: возможно, можно было сделать проще - чем-то вроде start-dedupjob -type Scrubbing d: -full
If you specify GarbageCollection for the Type parameter:
Indicates that garbage collection jobs free up all deleted or unreferenced data on the volume. If you do not specify this parameter, garbage collection jobs free up space after a system threshold of delete data is exceeded. We recommend that you run garbage collection regularly without specifying this parameter, and then once a month specify this parameter and run garbage collection again.
If you specify Scrubbing for the Type parameter:
Indicates that scrubbing jobs validate the integrity of all data on the volume. If you do not specify this parameter, the scrubbing job validates only critical metadata and data integrity issues that data deduplication previously encountered. We recommend that you run scrubbing regularly without specifying this parameter, and then once a month specify this parameter and run scrubbing again.
Отсюда.
Оно может собрать мусор и удалить. Или не собрать :)
Есть файл-сервер (2012r2), на котором на локальных дисках (физических) есть раздел (d:) и на нем поднята шара. В шаре лежат тестовые виртуалки Hyper-V (их диски, конфигурация и своп), с которыми работает файловер кластер из двух узлов, и в оперативной и на процессорах которого виртуалки и выполняются. Именно файловая шара, а не общий для кластера диск, используется по нескольким причинам - так удобнее мигрировать виртуалки с 2012 на 2012r2 без остановки виртуалок, кластер всё равно тестовый и еще одной физической хранилки не было.
Разные виртуалки мигрировали на этот кластер и хранилку и с него. Иногда после миграции (всё через live migration, не выключая) файлы виртуалок не удалялись, т.к. были заняты пользователем system. Разблокировка и удаление файлов уже несуществующей виртуалки происходило после рестарта ноды кластера, на которой жила эта виртуалка, или поочередного рестарта обеих нод.
Постепенно начали накапливаться необъяснимые глюки - место на диске (1.5 Тб, свободно было около 300 Гб) стало кончаться, при том что файлов виртуалок было явно не на столько много (а уж как оно это в GUI показывает - просто песня!), информация о свободном месте стала обновляться только после рестарта сервера, и, наконец, эффективность дедупликации стала стабильно 0%, при том что Get-DedupMetadata d: выдавало данные о работающей дедупликации:
Volume : D:
VolumeId : \\?\Volume{4ebd6280-55a5-4d4e-8284-a3e8448c09e5}\
StoreId : {21C34345-7466-4A88-8B23-280E5D51A6F7}
DataChunkCount : 29517961
DataContainerCount : 881
DataChunkAverageSize : 31.18 KB
DataChunkMedianSize : 0 B
DataStoreUncompactedFreespace : 0 B
StreamMapChunkCount : 174483
StreamMapContainerCount : 2791
StreamMapAverageDataChunkCount :
StreamMapMedianDataChunkCount :
StreamMapMaxDataChunkCount :
HotspotChunkCount : 309107
HotspotContainerCount : 9
HotspotMedianReferenceCount :
CorruptionLogEntryCount : 0
TotalChunkStoreSize : 1.05 TB
Включение и выключение дедупликации, рестарт сервера, чекдиск и т.п. не помогали. Помогла похоже только полная де-дедупликация диска, командой Start-DedupJob -type unoptimization -volume d: -preempt (результаты Get-DedupJob), при этом свободное место уменьшилось c ~300 до ~100Гб, а после завершения процедуры стало ~750Гб. Get-DedupMetadata d: больше ничего не выдает, а выдает теперь ошибку, т.е. дедупликация полностью выключена. Chkdsk никаких проблем ни до, ни после не находил. Вывод - вероятно, какие-то цепочки в chunk store оказались заблокированы hyper-v и из-за каких-то глюков не очистились, оставшись "потерянными кластерами", причем chkdsk на это не обратил внимание - для него это просто файлы.
Попробую вот сейчас включить назад и понаблюдать, процедура ремонта теперь понятна. На соседнем тестовом кластере (2.5 Тб хранилище, свободно 1.2 Тб , 30 небольших виртуалок под разной виндой) экономия от дедупликации 54% или 1.47 Тб, так что оно того стоит. Только разжать назад если что можно уже только с переносом виртуалок.
UPD: возможно, можно было сделать проще - чем-то вроде start-dedupjob -type Scrubbing d: -full
If you specify GarbageCollection for the Type parameter:
Indicates that garbage collection jobs free up all deleted or unreferenced data on the volume. If you do not specify this parameter, garbage collection jobs free up space after a system threshold of delete data is exceeded. We recommend that you run garbage collection regularly without specifying this parameter, and then once a month specify this parameter and run garbage collection again.
If you specify Scrubbing for the Type parameter:
Indicates that scrubbing jobs validate the integrity of all data on the volume. If you do not specify this parameter, the scrubbing job validates only critical metadata and data integrity issues that data deduplication previously encountered. We recommend that you run scrubbing regularly without specifying this parameter, and then once a month specify this parameter and run scrubbing again.
Отсюда.
Оно может собрать мусор и удалить. Или не собрать :)