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

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

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

11 комментариев:

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

    ОтветитьУдалить
  2. Анонимный8 июля 2011 г., 15:36

    Ctk же адреса только запичывает, и растет на мегабайт для гигабайта диска, нет?

    ОтветитьУдалить
  3. Буквально позавчера попали в подобный просак. ВМ файл-сервер на пару-тройку сотен гигабайт.Еженочный бэкап Net Veritas. Энтузиасты же поставили также еженочную дефрагменацию со сдвигом по времени от бэкапа. Непонятно почему бэкап задержался, совпал с дефрагментацией - и привет - снэпшоты выросли практически до размеров базовых дисков, место на сторадже кончилось, машина не включается.
    Хорошо, смогли освободить место SVmotion'ом пары других маленьких ВМ со стораджа. А то бы пришлось в рабочее время выключенный файл-сервер неизвестно сколько клонировать, соответственно downtime важнейшего корпоративного сервера,за что отымели бы всех...
    Самое смешное, что дефрагментацию оставили, передвинув еще по времени...покажу начальству этот пост, может одумаются.

    ОтветитьУдалить
  4. Анонимный8 июля 2011 г., 17:30

    Есть сомнения по поводу RAID Penalty
    Исходя из приведенных рассуждений, raid1 медленнее raid0 на запись в 2 раза, raid5 в 4 и т.д.
    Что показывают реальные измерения?

    ОтветитьУдалить
  5. Анонимный8 июля 2011 г., 20:29

    Так оно все и есть :-)

    Притом вы забыли добавить " на одном и том же количестве дисков", потому что если raid0 на N дисках, то он в N раз быстрее зеркала raid 1 из пары дисков.

    ОтветитьУдалить
  6. Поправлю про CBT. ctk-файл расти не должен - создается размером, в зависимости от размера соответствующего vmdk.

    Но, из-за дефрагментации будет отмечаться все больше количество изменившихся блоков в этой таблице. А стало быть придет бэкапер за инфой в следующую свою сессию, и выяснит, что копировать ему надо всю машину заново:
    1. Время бэкапа увеличилось (а при репликации по WAN это вообще может стать критично)
    2. Размер инкремента станет равным полной копии.
    3. Плюс задержка при пересобирании полной копии из таких инкрементов, или при восстановлении.

    ОтветитьУдалить
  7. Анонимный9 июля 2011 г., 0:02

    кстати давно хотел уточнить - cbt записывает изменения с последнего снапшота, так?

    т.е. если после бекапного снапшота был еще один вручную создан - схема нарушается?

    или я ошибаюсь?

    ОтветитьУдалить
  8. Admin, например пару дисков в RAID 1 и три-четыре ВМ.

    Анонимный, по поводу роста ctk - сорри, неточно выразился. vEskin пояснил.

    Анонимный, по поводу RAID penalty. Это теоретическая цифра, для сферического RAID в вакууме. Разумеется в реальности все оказывается несколько лучше за счет кэша, оптимизации и т.д.
    У меня не было цели рассказать о том как работает RAID. Если кому-то нужна это информация - http://ru.wikipedia.org/wiki/RAID

    ОтветитьУдалить
  9. Анонимный9 июля 2011 г., 8:02

    ну так поправь насчет ctk, сейчас там полная лажа написана.

    ОтветитьУдалить
  10. Сейчас не могу найти ссылки, но читал довольно большой отчет от гуру Windows по поводу дефрагментации в гостевой ОС. Если найду ссылку - кину.

    Суть заключений той серии статей - фрагментация в гостевой ОС приводит к росту числа IOPs генерируемых системой. Т.е. я читаю файл фрагментированный на 1000 частей, соответсвенно ГОС сгенерирует минимум 1000 операций (для каждого фрагмента). А после дефрагменатции например стало 100 частей, количество операций уменьшится значительно, хоть и не в 10 раз.

    В итоге, при фрагментации в гостевой ОС, ядру ESX хоста придется обработать большее число запросов от виртуалки. Сгладить ситуацию могут хорошие СХД/рэйды, сгрупировав кучу вирутальный операций в несколько физических... но вычислительная нагрузка на хосте и на контроллерах дисковой системы однозначно будет повышена.

    ОтветитьУдалить
  11. Возможно кто то захочет прокоментировать опыт работы или теоретическую необходимость след. продукта http://www.diskeeper.com/business/v-locity/

    ОтветитьУдалить