Дефрагментация динамического диска виртуальной машины Hyper-V

Все гипервизоры для Windows, позволяющие работать с виртуальными машинами и устанавливаемыми на них гостевыми ОС, в числе своих возможностей также предусматривают и какие-то операции по работе с виртуальными дисками машин. Hyper-V в этом плане можно считать продвинутым: у него есть отдельный специальный функционал по созданию, конфигурации и изменению виртуальных дисков. Этот функционал реализован в мастерах создания и изменения дисков, а также интегрирован в параметры виртуальной машины.

И вот одной из возможностей этого функционала является дефрагментация диска машины, если он динамического типа. Это операция по сжатию фактического объёма, занимаемого файлом диска VHD (либо же VHDX) . Давайте рассмотрим эту операцию.

Одной из характеристик виртуальных дисков являются их типы – фиксированный и динамический. Первый занимает на физическом жёстком диске ровно столько объёма, сколько мы указываем для него номинально при создании. И такой диск не вместит в себя по факту данных больше, чем его номинальный объём. Тип динамический не зависит от своего номинального объёма: он по факту на физическом диске занимает ровно столько места, сколько данных суммарно на него помещено. И его проблема в том, что после удаления данных с него его фактический объём на физическом диске не уменьшается. И такой диск по итогу различных передвижек данных может увеличиться в фактическом объёме до огромных значений. Его файл даже может захламить собой весь раздел физического диска. Чтобы этого не произошло для виртуальных машин Hyper-V, в которых используются динамические диски, необходимо время от времени проводить гигиеническую процедуру – дефрагментацию их дисков. Как её провести?

Дефрагментацию виртуальных динамических дисков можно выполнять с использованием любой реализации функционала по управлению дисками Hyper-V, но проще всего использовать этот функционал, интегрированный в параметры машины. В любом случае при проведении любых операций по изменению диска машины эта машина должна быть в выключенном состоянии. Если она включена, можем не запускать её для выключения, просто удаляем её сохранённое состояние.

Открываем параметры выключенной машины.

Слева окна параметров кликаем диск машины. И для начала посмотрим его свойства. В основной части окна возле нашего диска жмём кнопку «Проверить».

Откроется окошко его свойств, и здесь в числе сведений о характеристиках диска будут данные его объёма – номинального в графе максимального размера и фактического в графе текущего размера. В нашем случае фактический объём – 13,07 Гб.

Пока что это немного, но всё равно мы можем уменьшить фактический объём, сделать это, так сказать, на перспективу роста файла диска. Закрываем окно свойств диска и возвращаемся к кнопкам возле диска машины в её параметрах. И теперь нажимаем кнопку «Правка».

Запустится мастер изменения диска, на первом его этапе жмём «Далее».

На этапе выбора действия выбираем «Дефрагментировать».

И жмём «Готово».

Пару секунд будет выполняться дефрагментация. Затем мы снова вернёмся в окно параметров машины. И теперь можем посмотреть, насколько была эффективна проведённая нами процедура. Снова жмём кнопку возле диска «Проверить», смотрим его свойства. Текущий размер теперь у нас отображается 8,6 Гб.

Т.е. операция по дефрагментации динамического диска высвободила больше 4 Гб места на физическом диске. При больших оборотах работы с данными в среде виртуальной машины это будут, соответственно, значительно большие объёмы расчищенного на физическом диске места.

Включение и настройка шифрования BitLocker не представляет особой сложности, что, однако, не исключает появления проблем. Читать далее

Для шифрования дисков и томов в Windows 10 предусмотрена встроенная функция BitLocker, позволяющая шифровать как Читать далее

Нередко у пользователей возникает необходимость создать полный список всех имеющихся файлов в какой-либо папки или Читать далее

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

Записки виртуального админа

Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.

пятница, 8 июля 2011 г.

Имеет ли смысл дефрагментация диска в гостевой ОС?

Тема дефрагментации файловой системы периодически всплывает то на форуме, то просто в почте.

Так нужна ли дефрагментация в виртуальном мире, которая как известно, сильно помогает в мире физическом?

Начем с того, что такое фрагментация вообще и каково ее влияние на производительность. Итак, фрагментация — ситуация, когда блоки большого файла разбросаны по физическому диску в случайном порядке. Влияние фрагментации отлично видно на обычной домашней машине с одним жестким диском и большим количеством больших файлов (кино, фото и т.д.). В этом случае для чтения файла (например при копировании) головка диска не может осуществлять линейное последовательное чтение на максимальной скорости, а вынуждена метаться между блоками. Разумеется, все то время, что головка перемещается к нужному цилиндру и ждет начала блока с данными, чтения не происходит. Итог — снижение скорости чтения. Иногда кардинальное снижение, если файл оказался разбит на множество блоков малого размера.
Лечение — путем последовательных чтения/записи переместить по диску блоки файла таким образом, чтобы в максимальной степени сделать их последовательными и соотв. свести перемещания головки к минимуму.

Просто, очевидно и ведет к легко измеримому преимуществу. Но так ли это в виртуальном мире?

А вот здесь как раз зарыт бегемот.

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

1) Поскольку у нас есть массив из множества дисков, по которым равномерно размазаны данные, значительно снижается влияние перемещения головок — идет практически параллельное чтение с нескольких дисков, причем практически непредсказуемо.
2) Чем более интеллектуален дисковый массив, тем меньше само влияние самой медленной части дискового массива — дисков. Большой оперативный кэш, кэш второго уровня на флэш-дисках, многоуровненое хранение снижают влияние дисков вплоть до того, что до физических медленных магнитных дисков доходит иногда всего 10% операций чтения. Мощные процессоры, алгоритмы оптимизации и большой зеркалированный кэш с батарейкой позволяют не спешить записывать на диски поток команд как он идет, а делать это оптимальным образом в зависимости от уровня и прочих параметров RAID, в минимальное количество операций.
3) Одновременная нагрузка с десятков и даже сотен виртуальных машин привод к тому, что только внутри ВМ дисковые операции выглядят как линейное чтение. До дискового массива чтение/запись доходит уже как практически случайная последовательность команд. От того, что файл внутри из одной ВМ расположен непоследовательно, практически ничего не меняется.

Итого: если ВМ расположены на малоинтеллектуальном массиве начального уровня (или просто на внутреннем RAID сервера) на малом количестве физ. дисков (шпинделей), и их мало, то дефрагментация может иметь смысл и снизить нагрузку на дисковую систему / повысить общую производительность.
Однако с ростом размеров инфраструктуры и повышении класса дисковой системы фрагментация перестает играть сколько нибудь значимую роль. Зато дефрагментация становится не спасением, а самым настоящим злом. Вспомним, что собой представяет процесс дефрагментации — множество операций чтения / записи (1 к 1) в объеме, доходящим до 100% данных на диске.

1) Существует такое понятие, как RAID penalty — штраф к производительности в силу того, что используется RAID. Кратко, при использовании RAID 1 (1+0) каждая операция записи со стороны ВМ превращается в 2, когда доходит до дисков. Для RAID 5 — 4, RAID 6 — в 6! Итого, сам процесс дефрагментации очень сильно просаживает производительность. В случае же с флэш-дисками, еще и сильно сокращает срок службы.
2) Снапшоты. Вы же их используете? Дефрагментация вырастит снапшот до размеров базового диска легко и непринужденно. А кстати, вы не забыли, что снапшот сам по себе дает очень большой штраф к производительности дисковой системы? Который надо умножить на RAID penalty. А потом этот немеряно выросший как на стероидах снапшот надо коммитить. Что снова дает нам много-много записи, которую так не любит RAID.
3) Вы говорите не используете снапшоты? А как же VMware-level резервное копирование ВМ? Оно реализовано через снапшоты, и существуют совсем ненулевые шансы того, что встретятся вместе задания бэкапа и дефрагментации.
4) И кстати, вы используете для бэкапа Changed Block Tracking? забудьте о нем, дефрагментация вырастит статистику измененных блоков (хранится в ctk файле) вплоть до объема диска, и вместо быстрого инкрементального бэкапа вы получите медленный полный.
5) Тонкие диски (thin provisioning). Скажите им тоже «до свидания», при дефрагментации тонкие диски начнут очень быстро превращаться в обычные толстые, и все их преимущества будут сведены на нет.

Дефрагментация диска виртуальной машины?

Есть ли смысл выполнять дефрагментацию HDD средствами гостевой ОС?

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

Если я в ошибаюсь, прошу объяснить где именно.

• Вопрос задан более трёх лет назад
• 6973 просмотра

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

Если VM живёт на файле:
дефрагментация должна выполняться и на хосте и на виртуалке.
Потому что фрагментация может быть кошмарная (числа рандомные):
запрашивается файл. Гостевая видит, что он в LBA 5723-5730, 8765-8800 и просит эти сектора. Хост видит запрос, транслирует по фрагментации файла и с реального диска пойдут уже запросы, чтобы получить изначальные 5723-5728 с одной области диска, 5729-5730 с другой, 8765-8780 с третьей и 8780-8800 с четвёртой.

Так, если дефрагментировать хостовую ФС — получим 2 позиционирования диска, вместо 4х, если только гостевую — как повезёт (т.к. адресация гостя действительно не имеет ничего общего к хостовой), если обе сразу — то получим 1 операцию.

Если же взять в пример ту же самую гостевую систему, но дефрагментированную хостовую (что не редкость при использовании файла-образа фиксированного размера, который 1 раз положили и не трогают) — то, помимо некоторого оверхеда на обслуживание самого файла в ФС хоста и кучи разных кэшей, получаем прозрачную трансляцию адресов гостя в адреса физического диска и прямое влияние фрагментации гостевой ФС на работу диска.

Вадим Стеркин

У меня стало заканчиваться место на диске, и я первым делом проверил размеры VHDX-файлов своих виртуальных машин, где используются динамически расширяемые диски. На самой ненужной ВМ с экспериментальной Windows 10 размер файла составлял 51GB, что примерно соответствовало занятому пространству в гостевой ОС.

Я выполнил в ВМ очистку диска, удалив 25GB Windows.old и прочего мусора, что сократило занятое пространство до 22GB. Затем я выключил ВМ, в ее настройках перешел к редактированию диска и выбрал сжатие.

Но по завершении операции размер файла сократился всего на 3GB.

👉 Тогда я отключил в гостевой ОС файл подкачки, перезагрузился, выполнил в командной строке

и повторил сжатие. На сей раз оно достигло результата, уменьшив размер VHDX до ожидаемых 23GB.

На хосте можно применять такой же подход, отключив наряду с подкачкой еще и гибернацию, когда не получается толком сжать (shrink) раздел в оснастке управления дисками или diskpart.

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

В этом контексте остается вопрос дефрагментации физического SSD. Казалось бы, он изъезжен в блоге вдоль и поперек. Ан нет! Но об этом в следующий раз 😉

В комментариях напишите, сталкивались ли вы с тем, что невозможно сжать раздел средствами ОС до нужного размера, как решали задачу, случались ли косяки.

Upd. По разным каналам читатели советуют такие варианты решения задачи для виртуальных дисков Hyper-V и VirtualBox. Впрочем, два первых для Hyper-V могут споткнуться о системные файлы, которые нельзя переместить (для чего я и задействовал дефраг).

• Командлет PowerShell Move-VM с параметром -IncludeStorage (Денис Дягилев)
• Утилита sdelete с ключом -z (Дмитрий Кирушев)
• Руководство по сжатию виртуальных дисков в VirtualBox на англ. (Александр Белоглинцев)

Какой тип диска вы используете для экспериментальных ВМ?