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

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

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

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

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

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



Давайте представим себе среднего размера инфраструктуру с парой сотен виртуальных машин. Есть производительный массив с множеством дисков в 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). Скажите им тоже "до свидания", при дефрагментации тонкие диски начнут очень быстро превращаться в обычные толстые, и все их преимущества будут сведены на нет.

А казалось бы, как хорошо все начиналось...

Не все йогурты одинаково полезны.