Важное замечание. Статью писал несколько лет назад. Потому стоит учесть, что она касается VI3. В vSphere есть технология CBT (changed bloacks tracking), которая очень помогает для быстрого резервного копирования. В этом случае дефрагментация только ухудшит работу. Точно также дефрагментация отрицательно будет влиять на тонкие диски.
В любом случае, дефрагментация внутри ВМ не даст приращения в скорости, поскольку доступ к всему тому LUN, при наличии большого количества файлов дисков ВМ, доступ будет не последовательный, а случайный.
Рекомендация одна: выберийте быстрые массивы для файлов ВМ.
Попалась мне статья про дефрагментацию дисков ESX. Так, короткая заметка на английском. Есть несколько интересных замечаний. Почему бы мне ее не пересказать?
Стоит разбить тему на две части: дефрагментация информации на диске внутри виртуальной машины (ВМ), и дефрагментация самих дисков ВМ в разделе VMFS (файловая система для виртуальных машин).
По первому вопросу: да, стоит. Сильно фрагментированный диск будет тормозить дисковую подсистему ВМ.
Но, нужно учитывать следующее:
1. Дефрагментация сама по себе дает интенсивный ввод-вывод на диски, а значит будет влиять на всю дисковую подсистему, что затронет все ВМ на данной партиции, включая запущенные на других ESX-серверах. И самое главное: не дефрагментируйте все ВМ скопом! Хотя... есть неплохой шанс проверить ваш SAN на прочность ;)
Короче, выбирайте время для дефрагментации, и запускайте дефрагментацию по очереди.
2. А вот это серьезней, и менее очевидный риф: Не дефрагментируйте ВМ с активными snapshot'ами! Во-первых, ваш файл дисковой разницы будет очень быстро пухнуть - так как много изменений происходит внутри виртуального диска. А, во-вторых, дисковая подсистема для всех ваших ВМ в данной партиции VMFS будет жутко тормозить, потому как snapshot начнет расти 16МБ блоками, а каждое изменение в размере файла на VMFS приводит к локированию всей VMFS-партиции.
От себя добавлю, выход есть: вначале дефрагментация, потом snapshot.
Что касается второй части - дефрагментации файлов ВМ на VMFS-партиции, мне понравилась в той статье фраза:
"Ответим на этот вопрос: нет, по двум причинам. Во-первых, не существует механизма, ни встроенного, ни разработанного кем-то еще, который бы позволил это осуществить"
Отличное замечание, не правда ли? :) Вам вторая причина еще нужна?
"Вторая причина в том, что хост в реальности и не фрагментирует данные, ввиду принципа создания и работы виртуальных дисков на VMFS"
Ага, мне второе замечание тоже понравилось. :) Причины две: нет ни возможности, ни надобности.
А далее статья рассказывается сам принцип создания дисков ВМ. На самом деле данные все-таки могут фрагментироваться, но не так, как это происходит с файлами в обычных ОСах. Заметим, что в отличие от обычных операционнок, здесь складывается противоположная ситуация: хранятся, по большей части, огромные файлы и в относительно небольшом количестве.
Если вы создаете обычный ("толстый") диск ВМ, или копируете с помощью утилиты vmkfstools, то виртуальный диск будет создан максимально большим куском, как правило, единым блоком, а затем уже будет наполнятся данными в случае копирования.
Фрагментация может произойти, если был создан так называемый "thin" диск, который будет расти по мере необходимости нового пространства, или если вы ошибочно копируете диск другой ВМ с помощью SCP (пользуйтесь vmkfstools!).
Также фрагментация происходит, когда вы создаете и удаляете snapshotы, и при автоматическом создании/удалении разных сопутствующих мелких файлов ВМ: логи, свопы и слепки памяти и т.п.
Таким образом, возможна ситуация, когда при очередном создании нового виртуального диска система не сможет выделить под него единый блок. Но в таком случае, просто будут создано некоторое небольшое количество все равно больших блоков. При том блоков настолько больших, что фрагментация будет настолько мала, что ей можно просто пренебречь.
Так что на этот счет просто не парьтесь! ;)
В любом случае, дефрагментация внутри ВМ не даст приращения в скорости, поскольку доступ к всему тому LUN, при наличии большого количества файлов дисков ВМ, доступ будет не последовательный, а случайный.
Рекомендация одна: выберийте быстрые массивы для файлов ВМ.
Попалась мне статья про дефрагментацию дисков ESX. Так, короткая заметка на английском. Есть несколько интересных замечаний. Почему бы мне ее не пересказать?
Стоит разбить тему на две части: дефрагментация информации на диске внутри виртуальной машины (ВМ), и дефрагментация самих дисков ВМ в разделе VMFS (файловая система для виртуальных машин).
По первому вопросу: да, стоит. Сильно фрагментированный диск будет тормозить дисковую подсистему ВМ.
Но, нужно учитывать следующее:
1. Дефрагментация сама по себе дает интенсивный ввод-вывод на диски, а значит будет влиять на всю дисковую подсистему, что затронет все ВМ на данной партиции, включая запущенные на других ESX-серверах. И самое главное: не дефрагментируйте все ВМ скопом! Хотя... есть неплохой шанс проверить ваш SAN на прочность ;)
Короче, выбирайте время для дефрагментации, и запускайте дефрагментацию по очереди.
2. А вот это серьезней, и менее очевидный риф: Не дефрагментируйте ВМ с активными snapshot'ами! Во-первых, ваш файл дисковой разницы будет очень быстро пухнуть - так как много изменений происходит внутри виртуального диска. А, во-вторых, дисковая подсистема для всех ваших ВМ в данной партиции VMFS будет жутко тормозить, потому как snapshot начнет расти 16МБ блоками, а каждое изменение в размере файла на VMFS приводит к локированию всей VMFS-партиции.
От себя добавлю, выход есть: вначале дефрагментация, потом snapshot.
Что касается второй части - дефрагментации файлов ВМ на VMFS-партиции, мне понравилась в той статье фраза:
"Ответим на этот вопрос: нет, по двум причинам. Во-первых, не существует механизма, ни встроенного, ни разработанного кем-то еще, который бы позволил это осуществить"
Отличное замечание, не правда ли? :) Вам вторая причина еще нужна?
"Вторая причина в том, что хост в реальности и не фрагментирует данные, ввиду принципа создания и работы виртуальных дисков на VMFS"
Ага, мне второе замечание тоже понравилось. :) Причины две: нет ни возможности, ни надобности.
А далее статья рассказывается сам принцип создания дисков ВМ. На самом деле данные все-таки могут фрагментироваться, но не так, как это происходит с файлами в обычных ОСах. Заметим, что в отличие от обычных операционнок, здесь складывается противоположная ситуация: хранятся, по большей части, огромные файлы и в относительно небольшом количестве.
Если вы создаете обычный ("толстый") диск ВМ, или копируете с помощью утилиты vmkfstools, то виртуальный диск будет создан максимально большим куском, как правило, единым блоком, а затем уже будет наполнятся данными в случае копирования.
Фрагментация может произойти, если был создан так называемый "thin" диск, который будет расти по мере необходимости нового пространства, или если вы ошибочно копируете диск другой ВМ с помощью SCP (пользуйтесь vmkfstools!).
Также фрагментация происходит, когда вы создаете и удаляете snapshotы, и при автоматическом создании/удалении разных сопутствующих мелких файлов ВМ: логи, свопы и слепки памяти и т.п.
Таким образом, возможна ситуация, когда при очередном создании нового виртуального диска система не сможет выделить под него единый блок. Но в таком случае, просто будут создано некоторое небольшое количество все равно больших блоков. При том блоков настолько больших, что фрагментация будет настолько мала, что ей можно просто пренебречь.
Так что на этот счет просто не парьтесь! ;)
Вопрос очень актуальный. К сожалению я не могу спрогнозировать необходимый объем диска поэтому всегда делаю 'thin'. Я с этим борюсь следующим образом:
ОтветитьУдалить1) делать как можно меньше снапшотов, и при возможности удалить старые
2) после зачистки снапшотов. и долгой эксплуатации ВМ переношу её на другой датастор, при помощи migrate.
1) Снапшоты - вообще зло. И стоит использовать редко и для специфических случаев: резервное копирование, обновление ВМ, установка ПО.
Удалить