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, и какой эффект она вам даст, вам следует найти ответы на ряд вопросов, связанных с вашей системой и данными на ней хранящимися.
- Насколько сильно, в процентном отношении, заполнены активными, изменяющимися, а не просто хранящимися данными, заполнены диски, конкретнее - тома на aggregate?
- Каков процент свободного места на томах и aggregate? (помните, что WAFL – структура thin by design, и для нее 100% занятый пустыми томами aggregate – пустой)
- Насколько активно используется на томах deduplication, и сколько места она у вас высвобождает.
- Наконец, насколько часто вы расширяли тома и aggregate физическими дисками?
На первые два вопроса ответ, и то как он соотносится с темой необходимости реаллокации, вы, скорее всего уже знаете. Если на диске в момент записи достаточно свободного места, то подсистема, выделяющая на диске место по запросу OS в форме дисковых экстентов, или протяженных сегментов блоков, с легкостью найдет и выделит процессу записи любое нужное количество блоков в единой цепочке. ??менно по этой причине в таких файловых системах, как ext2/3 и NTFS фрагментация файлов в самом деле принципиально ниже, чем в FAT, где OS не использует такое “групповое выделение” блоков, и занимает их по порядку, один за одним, не обращая внимание на то, где и как они расположены. Разумеется такой вариант, особенно в активной и, как это называется, aged, то есть давно используемой в работе файловой системе, вызывает существенное дробление фрагментов файла по диску.
Это не так в уже перечисленных “BSD-like” системах и NTFS. Пока на файловой системе есть достаточно свободного места, механизм выделения цепочек последовательных блоков работает хорошо. Сложности начинаются тогда, когда файловая система заполняется файлами, которые произвольно создаются и удаляются, и постепенно структура блоков данных начинает напоминать сыр с его дырками, когда вроде место и есть, но оно все “пузырьками”. Дело в том, что если последовательный экстент блоков нужной длины на дисковом томе найти не удается (а данные писать все ж таки надо), то описываемая подсистема OS говорит файловой системе: “ну ОК, давай мне два покороче, пусть в разных местах. Нету? Ну что-ж, ну а четыре еще короче есть?”. ?? такое дробление продолжается до тех пор, пока вся последовательность, ожидающая записи на диски не будет записана.
Очевидно, что чем меньше у файловой системы будет “пространства для маневра”, то есть последовательно свободного пространства на томе, и чем больше будет на этот том записей и перезаписей, тем сложнее ей будет с каждым разом находить связные последовательно куски блоков. ??менно по этой причине, например, Windows тревожно закрашивает красным диск, слишком сильно заполненным данными. Если это диск с файловой системой, которая не просто залита фильмами, как на скриншоте ниже, а активно обновляется, записывается и перезаписывается данными, то вскоре вы увидите, что коэффициент фрагментации файлов, ранее невысокий, на ней вдруг начнет резко расти, ухудшая ее характеристики производительности.
Напомню, что рекомендуется поддерживать 10-15% свободного места на томе и aggregate для нормальной работы описанных выше механизмов (это примерно совпадает с рекомендациями MS для NTFS), причем на уровне aggregate это пространство уже зарезервировано в WAFL reserve, недоступном пользователю.
Подводя итоги по этой части хочу специально указать: это рекомендация, но не требование. Вы МОЖЕТЕ заполнить диск данными на все 100% его емкости. ?? в ряде случаев, например как на картинке выше, где приведен скриншот моего лэптопа, и где выделенный диск есть хранилище бэкапов, фильмов и музыки, то есть записи на него нерандомны и крайне редки, это не имеет большого значения и мало влияет на его производительность.
Но если ваши данные активно перезаписываются, и у вас есть возможность не заливать их на том “с горкой”, то оставьте побольше свободного места на томе (и на aggregate для thin-томов) – не пожалеете :)
??так, чтобы не раздувать один пост, продолжим на следующей неделе.
