Reallocation в Data ONTAP. Часть 1.

Многие мои посты тут пишутся заранее, и потом отлеживаются. Некоторые – отлеживаются в моей голове. Но среди них есть порой и настоящие старожилы, вот, например, посту на тему того, как работает reallocation в WAFL и Data ONTAP, скоро уж три года. Все это время я пытаюсь сложить полноценную, непротиворечивую и исчерпывающую картину вопроса, чтобы изложить это все в блоге. Проблема в том, что, вследствие закрытости многих механизмов работы Data ONTAP (а также того, что они меняются, а закрытость позволяет не рассказывать публике об изменениях в деталях), многие вопросы остаются для меня не исчерпывающе отвеченными. Но, тем не менее, давайте перестанем тянуть кота за хвост, и приступим к тому, что нам известно, и о чем можно рассказать.

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

О том, насколько на самом деле так называемая “фрагментация” на WAFL влияет на производительность я уже писал не раз, не стану повторяться, все есть по ссылкам выше, сегодня поговорим об обратном процессе, что же представляет собой процесс reallocation.

Reallocation – это фоновый процесс в OS Data ONTAP, который оптимизирует и перераспределяет структуру хранения блоков WAFL для оптимизации к ним доступа. Он близко связан с тем, как именно происходит запись данных на WAFL в OS Data ONTAP. Не вполне корректно называть процесс реаллокации - “дефрагментацией”, как и проводить аналогии с файловой системой, например FAT, построенной на совсем иных  принципах выделения пространства. Многие годы считалось, например, что файловые системы Linux (читай inode-овые BSD-like файловые системы, с использованием идей которых создана и WAFL) вообще не подвержены фрагментации, так, до ext4 там вообще не существовало штатных средств “дефрагментации”, и ничего, работали же, а многие системы в продакшне и на ext3fs работают и до сих пор. Но, конечно, фрагментация, или, корректнее non-contiguous file allocation существует и в них, и с ростом дисковой нагрузки на серверные системы в целом, и увеличении объемов хранения, несомненно эта проблема стала все более заметной. Оставим сейчас в стороне спор, насколько фрагментация данных влияет в условиях, когда практически 100% workload составляет не sequental, а random access, об этом я уже писал, поговорим о том, что же можно сделать для оптимизации структуры хранения путем вот этой самой block reallocation. Подобной “фрагментации” данных подверженны все системы хранения (особенно использующие современные фишечки работы с данныеми, такие как снэпшоты, дисковые пулы, thin provisioning, а не просто dumb SCSI LUN). Но не все умеют с этим бороться.
NetApp – умеет.

В документации сказано скупо:

reallocate - Command for managing reallocation of files, LUNs, volumes, and aggregates

The reallocate family of commands manages the allocation, or layout optimization, of large files and
LUNs on a node. Additionally all files in a volume may be reallocated, and the block layout of
aggregates may be optimized. Using the reallocate command, layout measurement and optimization
(reallocation) can be automated.

Определенную сложность для пользователей вызывает тот факт, что процесс reallocate не запущен на системе по умолчанию. Сделано это, по всей видимости, исходя из главного принципа, которым руководствуется NetApp, назначая свои значения по умолчанию. Даже если вы не прочтете ни одной страницы документации, и запустите систему хранения “энтером” (то есть просто тупо давя Enter на все вопросы, соглашаясь на все установки по умолчанию), то даже при сочетании самых нелепых решений, данные не будут повреждены и система будет, пусть неоптимально, но работать. В общем тот самый врачебный Noli Nocere! - “Не навреди!”. Реаллокация может быть не нужна в ряде профилей использования. Но даже когда она не нужна, а она запущена по умолчанию, и при этом вы об этом не знаете, она неизбежно занимает какую-то долю системных ресурсов, и лучше было бы, чтобы, если уж она запущена, то запущена она была “по делу”, и понимающим это человеком.

Вот поэтому по умолчанию, на свежеустановленной системе процесс reallocation не запущен автоматически и не работает.

Для того, чтобы понять, нужна ли вам reallocation, и какой эффект она вам даст, вам следует найти ответы на ряд вопросов, связанных с вашей системой и данными на ней хранящимися.

  1. Насколько сильно, в процентном отношении, заполнены активными, изменяющимися, а не просто хранящимися данными, заполнены диски, конкретнее - тома на aggregate?
  2. Каков процент свободного места на томах и aggregate? (помните, что WAFL – структура thin by design, и для нее 100% занятый пустыми томами aggregate – пустой)
  3. Насколько активно используется на томах deduplication, и сколько места она у вас высвобождает.
  4. Наконец, насколько часто вы расширяли тома и aggregate физическими дисками?

На первые два вопроса ответ, и то как он соотносится с темой необходимости реаллокации, вы, скорее всего уже знаете. Если на диске в момент записи достаточно свободного места, то подсистема, выделяющая на диске место по запросу OS в форме дисковых экстентов, или протяженных сегментов блоков, с легкостью найдет и выделит процессу записи любое нужное количество блоков в единой цепочке. Именно по этой причине в таких файловых системах, как ext2/3 и NTFS фрагментация файлов в самом деле принципиально ниже, чем в FAT, где OS не использует такое “групповое выделение” блоков, и занимает их по порядку, один за одним, не обращая внимание на то, где и как они расположены. Разумеется такой вариант, особенно в активной и, как это называется, aged, то есть давно используемой в работе файловой системе, вызывает существенное дробление фрагментов файла по диску.

Это не так в уже перечисленных “BSD-like” системах и NTFS. Пока на файловой системе есть достаточно свободного места, механизм выделения цепочек последовательных блоков работает хорошо. Сложности начинаются тогда, когда файловая система заполняется файлами, которые произвольно создаются и удаляются, и постепенно структура блоков данных начинает напоминать сыр с его дырками, когда вроде место и есть, но оно все “пузырьками”. Дело в том, что если последовательный экстент блоков нужной длины на дисковом томе найти не удается (а данные писать все ж таки надо), то описываемая подсистема OS говорит файловой системе: “ну ОК, давай мне два покороче, пусть в разных местах. Нету? Ну что-ж, ну а четыре еще короче есть?”. И такое дробление продолжается до тех пор, пока вся последовательность, ожидающая записи на диски не будет записана.

Очевидно, что чем меньше у файловой системы будет “пространства для маневра”, то есть последовательно свободного пространства на томе, и чем больше будет на этот том записей и перезаписей, тем сложнее ей будет  с каждым разом  находить связные последовательно куски блоков. Именно по этой причине, например, Windows тревожно закрашивает красным диск, слишком сильно заполненным данными. Если это диск с файловой системой, которая не просто залита фильмами, как на скриншоте ниже, а активно обновляется, записывается и перезаписывается данными, то вскоре вы увидите, что коэффициент фрагментации файлов, ранее невысокий, на ней вдруг начнет резко расти, ухудшая ее характеристики производительности.

image

Напомню, что рекомендуется поддерживать 10-15% свободного места на томе и aggregate для нормальной работы описанных выше механизмов (это примерно совпадает с рекомендациями MS для NTFS), причем на уровне aggregate это пространство уже зарезервировано в WAFL reserve, недоступном пользователю.

Подводя итоги по этой части хочу специально указать: это рекомендация, но не требование. Вы МОЖЕТЕ заполнить диск данными на все 100% его емкости. И в ряде случаев, например как на картинке выше, где приведен скриншот моего лэптопа, и где выделенный диск есть хранилище бэкапов, фильмов и музыки, то есть записи на него нерандомны и крайне редки, это не имеет большого значения и мало влияет на его производительность.

Но если ваши данные активно перезаписываются, и у вас есть возможность не заливать их на том “с горкой”, то оставьте побольше свободного места на томе (и на aggregate для thin-томов) – не пожалеете :)

Итак, чтобы не раздувать один пост, продолжим на следующей неделе.

10 комментариев

  1. Александр:

    Добрый день!
    Хотелось бы уточнить по поводу WAFL reserve.

    Неоднократно встречал упоминания, что при заполнении диска более чем на 90% приведет к ощутимой потере производительности. Так вот, WAFL reserve учитывает как раз это, или же рекомендации заказчику для систем с высокой нагрузкой не забивать до конца таки актуальны?

    Ну то есть вопрос снова сводится к usable space…

  2. vladmv:

    Спросил у одного клиента, почему они не включают Дедупликацию на системе FAS2020A 12*1Tb Complete.
    Оказалось, что ограничение на lun дедупликации - 1Тб. Естессно у них больше.
    Хотелось бы больше говорить в блоге про такие штуки. И как с ними потом бороться.

  3. Александр:
    Тут на самом деле есть темное место (одно из). Есть пространство на уровне aggregate (и оно в WAFL reserve, судя по всему, включено), и есть пространство на уровне тома (volume). При определенных условиях, например при большом (sic!) количестве перезаписей данных на томе, запас на томе даст прямой эффект в увеличении производительности.
    Это, конечно, спор о наполовину полном или наполовину пустом стакане, но специально уточню, не “снижение производительности при заполнении”, а “увеличение производительности при наличии свободного места (и определенном типе workload)”. Это важно, потому что за “норму” NetApp принимает именно заполненный на 90% том (и именно сверх этого уровня вы получаете прибавку), и, во-вторых, речь идет не о любой рабочей нагрузке, а об определенной, с большим числом перезаписей мелкими блоками. Это я упомянул в тексте выше.
    Кроме этого я в этом блоге постил на эту тему хороший перевод: http://blog.aboutnetapp.ru/archives/1083

    Так что ответ на вопрос: это гибко и вы выбираете, хотите ли вы плюс, допустим, 20% за счет неиспользуемой емкости дисков, сверх того, что вы купили как “производительность на данной системе”, или же вам важнее хранимые объемы, тогда прироста нет, вы получаете то, за что заплатили.
    Откровенно говоря, сегодня, в особенности для больших систем где число дисков измеряется десятками и полками, получить +20-30% для работающей системы просто по цене жестких дисков - отличный deal :)

  4. vladmv:
    А что про это писать, это написано в документации. Это ограничение на данной модели контроллера, оно опубликовано, пресейлы должны это знать и говорит об этом покупателю, соответственно покупатель должен это учитывать.
    Говоря технически, оно вызвано предельно небольшим объемом памяти контроллера для данной модели. Дедупликация это процесс, довольно крепко едящий при работе память. Если памяти начинает не хватать, то в первую очередь начнет страдать производительность (память же нужна не только дедупликации, но и другим процессам контроллера, да и просто кэшу). Поэтому было принято совершенно грамотное решение - ограничить потребление памяти дедупликацией, чтобы это не пошло в ущерб общей производительности системы.

    Соответственно решение - если нужна дедупликация на слабой системе типа 2020, то дробить пространство хранения на тома размером не более 1TB. Причем обращу внимание, тома нельзя уменьшить shrink-ом до этой величины, они должны быть созданы такого размера.

    Но вообще говоря, 2020 это уже несколько лет как не актуальная система, с появлением Data ONTAP 8.0 и контроллеров с ней работающих, эти лимиты стоят уже довольно высоко, а начиная с мидренджа и выше, кажется, и вовсе равны предельному размеру тома,

  5. Александр:

    Спасибо, как раз этот документ я и упустил. Все-таки правильный ответ делать некоторый буффер с запасом свободной емкости помимо WAFL reserve.

  6. Александр:
    Да, официальный Best Practices - оставлять на томе место (если на томе часто пишут). Это так для любых smart-стораджей с файловой системой, выше я это показываю для Windows и NTFS.
    Да, это не так сильно проявляется для dumb SCSI LUN (но все равно есть, просто не так сильно, и немного по другой причине), но кто сегодня использует dumb LUN, даже у EMC сегодня всюду storage pools, а Чак вон из EMC вообще уволился (или, вернее, перешел в VMware), видимо так и не смирился с таким “кидком” со стороны его компании. ;D

  7. Alexander:

    Не могу сообразить, почему reallocation физических блоков (ключ -p) вызывает такие эффекты:
    “Using the -p option may reduce the extra storage requirements in a flexible volume when reallocation is run on a volume with snapshots. It may also reduce the amount of data that needs to be transmitted by SnapMirror on its next update after reallocation is performed on a SnapMirror source volume”.

  8. Александр:

    Офф: …Сколько Александров стало в блоге

  9. “Ничего-ничего, зовите меня просто “Александр Первый” :)

  10. Илья:

    Рома, не совсем понял про заполненность томов. Насколько я помню NetApp всегда говорил про свободное место на агрегате и производительность, но про тома я слышу впервые. То есть, если я на томе с луном с резервацией места оставляю 1 Гб свободного места при общем объеме тома в 400 Гб, то у меня падает производительность? Есть какие то документы подтверждающие это?

    По поводу производительности агрегата: сам недавно искал официальное подтверждение про 90% занятого места на агрегате. Думаю стоит добавить в статью: https://kb.netapp.com/support/index?page=content&id=2017993&locale=en_US

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

20/0.146

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.