Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
О “дефрагментации” | about NetApp

О “дефрагментации”

“Усилиями” наших конкурентов все нынешние и будущие пользователи NetApp проинформированы, что “у этих netapp”, дескать, “огромная фрагментация”. Как обычно в области FUD (Fear, uncertainty and doubt), строится это все вокруг плохого понимания предмета, слабой технической подготовки “обрабатываемого”, а порой и откровенной манипуляции фактами. Отсутствие же ясного понимания темы, к сожалению, вызывает к жизни довольно много “техномистицизма” и накрученных вокруг догадок и слухов, которые, как и положено слухам, кормят и размножают сами себя.

В четверг я опубликую заметку о “теории” возникновения фрагментации на дисках вообще, интересующиеся отсылаются в нее. А пока хотел лишь обратить внимание читателей на прискорбную тенденцию, с которой встречаюсь уже не впервой.

Пользователи NetApp, которые не особенно копенгаген в технических деталях, но которым надули в уши про “ужасную фрагментацию на NetApp”, считают, что раз что-то на NetApp, значит это что-то надо “дефрагментировать”, и чем чаще, тем лучше. Причем под “дефрагментировать” обычно понимается виндовый defrag.exe, или же еще какой Diskeeper. 
Прискорбное заблуждение.

Еще более прискорбным оно становится, если дело происходит на диске виртуальной машины.

Если вы внимательно прочли наш переводной Best Practices по работе с VMware или Hyper-V,то должны были обратить внимание на строгое указание не использовать дефрагментатор OS на дисках, расположенных на системе хранения NetApp, будь то iSCSI/FC LUN, смонтированный на сервер, или же VHD/vmdk виртуальной машины.

Дело в том, что дефрагментатор в OS, это программа, которая ничего не знает о той, часто непростой структуре, что лежит под тем, что она считает “обычным жестким диском”. Она видит нечто (LUN), которое представляется ей обычным жестким диском, с секторами, головками и цилиндрами, но в случае LUN все это не имеет настоящего физического смысла. Под таким “псевдо-диском” могут лежать структуры RAID, или те или иные структуры организации его физических блоков (в случае NetApp – WAFL, в случае других систем, других вендоров – другие структуры) . На этом уровне работает непростая  дорогостоящая логика оптимизации доступа в больших системах хранения, которая знает как, и умеет оптимизировать доступ к своим данным. ? вмешательство в эту логику примитивной “дефрагментации” на уровне OS не только бессмысленно, но и нежелательно. ? уж точно никак с помощью defrag.exe не справиться с проблемой “фрагментации данных на NetApp”, ситуацию можно только ухудшить.

В случае конкретно NetApp, выполнение “дефрагментации” на уровне клиентской OS или виртуальной машины:

  1. Резко увеличивает объемы, занимаемые снэпшотами, так как пространство диска на NetApp со взятым снэпшотом занимает только изменения (записи), сделанные на нем после создания снэпшота, а “дефрагментация” при работе перезаписывает почти весь диск, то вы обнаружите, что снэпшот после такой “дефрагментации” практически удвоит занимаемое вашим томом на дисках место
  2. Портит оптимизацию доступа на уровне системы хранения, так как то, что, по мнению дефрагментатора, лежит рядом и последовательно, физически, на уровне системы хранения, и собственно физических дисков, может лежать совсем НЕ рядом и НЕ последовательно, и наоборот.
  3. Замусоривает кэш и загружает канал ввода-вывода бессмысленными операциями.

? в итоге – не приводит ни к чему, так как “фрагментацию” на уровне самого NetApp так не исправить, скорее наоборот, многочисленными перезаписями ее можно только ухудшить.

Если вы все равно не осилили все написанное выше, то просто следуйте простым советам:

  • Не используйте дефрагментацию в OS (defrag.exe, Diskeeper, Norton Defrag, etc.) для данных, расположенных на системе хранения NetApp. В том числе отключите автоматическую оптимизацию (Boot Time Optimization) и фоновую дефрагментацию дисков в OS Windows.
  • Не обращайте внимания на величины “фрагментации”, указываемые самой OS для LUN-ов и дисков виртуальных машин, размещенных на NetApp.
  • Для минимизации эффекта фрагментации записи непосредственно на дисках системы хранения NetApp используйте включение по расписанию встроенный в Data ONTAP реаллокатор (reallocate on / reallocate start [/vol/volname]).

 

 

ЗЫ. Вообще писалось все это смешно. Я сел а ноут, написал заголовок: “Несколько слов о дефрагментации”, и начал писать. Спустя два часа и примерно к конце третьего килобайта написанного я остановился, хмыкнул, посмотрел на заголовок… ? удалил из него “Несколько слов”, так как на “несколько слов” получающийся трактат никак не тянул. :)
В конце концов я решил разделить тему. В первую часть вынести все же “несколько слов”, те, которые и намеревался написать, а в четверговый пост пустить всю остальную “теорию большого взрыва”, которую, возможно, кому-то захочется прочитать, чтобы разобраться в деталях темы.

3 комментария

  1. Dmitriy:

    Роман, а можно подробней, про то как дефрагментнация на уровне ОС, может увеличить размер снапшота на уровне СХД? Ведь данные при дефрагментации, “перемащаются” (по сути уплотняются, смещаются к началу “физического” диска (Lun)), как такая перетасовка данных может увеличить размер снапшота? Ведь на NetApp при этом не возникает новых данных…

  2. Dmitriy:
    Тут вот какой механизм. Как вы знаете (из моей статьи про снэпшоты, например;) снэпшоты в NetApp устроены таким образом, что при создании он места на диске не занимает.
    Мы имеем один набор блоков, на который ссылается “таблица размещения файлов” текущего, активного состояния файловой системы, и “таблица” снэпшота. Таблица сама занимает какие-то килобайты, но это неважно. Обратившись в активную файловую систему мы, руководствуясь ее таблицей считаем блоки данных, и обратившись к таблице снэпшота считаем те же данные.

    Теперь на диск начинаются записи. Запись в WAFL реализована таким образом (опять же, вы это знаете из статьи про WAFL;), что в ней не перезаписываются старые блоки, а пишутся новые, если на старые уже есть активная ссылка из “таблицы” снэпшотов.
    Значит если мы (пере)запишем (для WAFL это одна и та же операция) один блок на WAFL, то мето, занимаемое на диске снэпшотом, которое было 0, увеличится на один блок. Запишем два - увеличится на два. Перезапишем все блоки - объем тома увеличится вдвое, потому что у нас в нем теперь будет два комплекта блоков, один - тот который был вначале, он “заперт” в снэпшоте, а второй - блоки, которые мы перезаписали новым значением.

    Снэпшот и файловая система теперь не шарят ни одного блока, каждый ссылается на свой набор в N-блоков. Занятое пространство увеличилось вдвое. Один набор блоков занимает active filesystem, второй - снэпшот.

    Это та ситуация, ради которой рекомендовалось в свое время устанавливать fractional reserve равным 100% от емкости тома, чтобы в случае массированной перезаписи не столкнуться с исчерпанием свободных блоков на запись.

    С точки зрения WAFL дефрагментация это та же самая запись. Она берет и “трогает” все (или почти все) блоки диска по очереди, перезаписывая их.
    То что при этом содержимое блоков не меняется WAFL не видит, у нее нет таких средств, видеть содержимое блоков, для нее есть просто операция записи в блок NNN, изменяющая его, для чего надо выделить новый блок из пула свободных. Тот же, который при этом “удаляется” не может быть удален, так как у нас есть снэпшот, на него ссылающийся.

    Таким образом если у вас есть том с данными, и есть снэпшот с него, , один или несколько, которые занимают, допустим 10-15% (на самом деле это не они “занимают”, это новые и измененные блоки активной файловой системы, с момента взятия снэпшота, занимают) и вы запустили дефрагментацию, то по мере ее работы, вы увидите, как объем снэпшотов на диске в выводе df стремительно увеличивается.

    UPD (12.04): Уточню, что это НЕ ОТНОС?ТСЯ к процессу реаллокации, выполняемой внутри системы хранения, ее встроенными средствами (reallocate on / reallocate start [/vol/volname])
    Реаллокация выполняется внутренними средствами и “знает” о том как выплняется этот процесс, он для системы “внутренний”, происходит с учетом ее внутреннего устройства, увеличения объема места, занимаемого снпшотами, в результате реаллокации, не происходит.

    Поэтому надо разделять “дефрагментацию” на стороне хост-системы, и “дефрагментацию” (я в дальнейшем, для избежания путаницы буду их называть “дефрагментация” и “реаллокация”) внутри самой системы хранения, силами ее собственной OS Data ONTAP.

  3. Дмитрий Прокудин:

    Роман, здравствуйте!
    Хорошая статья, все Вы в ней говорите правильно.

Оставить комментарий

20/0.088

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.