about NetApp

На прошлой неделе мы начали собирать в кучку все то, что мы знаем о процессе reallocate в Data ONTAP. В части первой я особо остановился на том, чем отличается знакомая вам всем “фрагментация” на файловых системах типа FAT, и чем она отличается от inode-овых экстентных FS, ведущих свое происхождение от BSD, и почему нельзя напрямую называть non-contiguous block allocation – “фрагментацией”, как это часто делается в говнилках. Равно как и называть процесс reallocate – “дефрагментацией”, хотя отчасти в его задачу действительно входит процедура оптимизации размещения блоков WAFL. Сегодня сосредоточимся именно на reallocate и его работе.

Одна из ключевых проблем WAFL, требующих использования reallocate, это так называемые “дисковые hot spots” аномально загруженные физические диски в нем, если брать их в сравнении с остальными дисками на aggregate. Происходит это вот от чего обычно.

Представим себе, что у нас есть aggregate из нескольких дисков. Диски постепенно заполняются данными.

В какой-то момент мы решаем, что aggregate нужно расширить, и добавляем в него несколько физических дисков. Это возможно, и довольно часто используется.

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

Возникает так называемый disk hot spot.

(“свежие”, а потому активные данные, скопились на нескольких добавленных дисках)

Оценить сравнительную загрузку физических дисков в aggregate можно с помощью вывода команды stats, или искользуя скрипты, их использующие, о некоторых я уже писал. Если вы уже побежали мерять свою систему, замечание вдогонку: вы, возможно, заметите на ней два сильно недозагруженных, по сравнению с прочими, диска в каждой RAID-группе (это видно и на скриншоте в посте выше). Да, это Parity и Double Parity диски RAID-группы, при штатной работе системы это нормально, не обращайте на это внимания, смотрите на те, которые выше и постоянно выше среднего по группе загружены.

(обратите внимание на параметр ut% (utilization) для диска 0d.26 на скриншоте выше)

Кстати сказать, описанная выше ситуация не является эксклюзивной для NetApp, например та же проблема встречается в disk pools на EMC VNX, и это именно та причина, по которой EMC не рекомендует добавлять в пул лишь по нескольку отдельных дисков, а только в количестве, кратном уже имеющейся емости RAID-групп пула, что очевидно, довольно жестокая негибкость для кастомера. У VNX ситуация усложняется еще и тем, что довольно долго после релиза системы у них не было вообще никаких средств реаллокации блоков и способов развномерно “растасовать” блоки при расширении пула.

Вот как раз в такой ситации нам на помошь придеть reallocation. С его помощью вы сможете равномерно перераспределить блоки с имеющихся дисков, на все, включая новые добавленые. Одна из причин возникновения “хотспотов” таким образом будет устранена. Помните, однако, что вам необходимо проделать это со всеми томами данного aggregate, о этом аспекте мы поговорим подробнее в части третьей. На приведенном рисунке я нарисовал простейшую схему с одним томом на aggregate, обычно же у вас несколько томов, а операция volume reallocate работает с отдельным томом, а не с aggregate в целом. Существует, однако, опция aggregate reallocation, но она предназначена для другого, об этом также отдельно.

Вот в чем причина, почему в случае расширения aggregate вам скорее всего будет крайне полезно сделать reallocate. Польза от его использования зависит, как вы видите из изложенного выше, от многих факторов. Когда-то она может и вовсе не проявиться, когда-то быть довольно существенной.

Например в communities.netapp я однажды нашел такое мини-исследование по результатам добавления дисковой полки к системе FAS2020 (aggr0 – 10 дисков, default RAID group size (16)). Дискова полка на 14 дисков к уже имеющимся 12 дискам  – это не тот случай, который вызовет явно наблюдаемые хотспоты дисков, но все же результаты интересные:

Крайние правые столбцы – система на нагрузке под SQL Server до добавления дисков (64K blocks, 100% random, 65% read/35% write). Средняя группа столбцов – сразу после добавления и без reallocate. Как вы видите, предсказуемо выросли IOPS, уменьшился responce time. Однако после добавления полки и измерения была проведена volume reallocation (в процессе ее CPU util - ~70-75%, disk util ~65%) с параметрами:

reallocate –f –p /vol/volX

Вы видите, что в результате несколько выросли показатели по IOPS, и несколько снизились показатели response time. Непринципиально, но процентов 15 таким образом удалось на системе наковырять. По моим оценкам польза от reallocation (и, кстати, соответственно, “вред” от пресловутой “фрагментации на NetApp”, вниманию любителей верить говнилкам) примерно в 10-15% и укладывается, в самых синтетически ужасных случаях на моих тестах – 20-25%.

Продлолжение следует.

Многие мои посты тут пишутся заранее, и потом отлеживаются. Некоторые – отлеживаются в моей голове. Но среди них есть порой и настоящие старожилы, вот, например, посту на тему того, как работает 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 тревожно закрашивает красным диск, слишком сильно заполненным данными. Если это диск с файловой системой, которая не просто залита фильмами, как на скриншоте ниже, а активно обновляется, записывается и перезаписывается данными, то вскоре вы увидите, что коэффициент фрагментации файлов, ранее невысокий, на ней вдруг начнет резко расти, ухудшая ее характеристики производительности.

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

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

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

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

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

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

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

Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз OLTP, для виртуализованных серверных сред почти 100% доступа к данным является рандомным? Последовательный, “секвентальный” доступ встречается в очень узком сегменте, это бэкапы (а у NetApp, к слову, задача бэкапа, как вы помните, решается другим способом, а не последовательным копированием и передачей данных), это базы с характером доступа DSS, и это, отчасти, логи баз данных. Вот, в общем, и все использование секвентального доступа. Остальное все – более или менее чистый рандом.

Поэтому я взял паттерн доступа VM-сервер (40%-write/60%-read, 45%-sequental/55%-random, 4KB block). Секвентальность в последнем случае берется вследствие работы локального кэша хоста. Паттерны эти определил не я, они довольно широко распространены. Вот его и будем кушать мерять.

Тестировал я с помощью IOmeter, который, несмотря на некоторые его недостатки, знаю и люблю. В качестве load-generator использовались виртуальные машины, работающие с достаточно мощного хоста (IBM 3850 X5), который был подключен к стораджу по NFS. Для OS в VM диск выглядел “физическим” LUN без файловой системы, который делался MBR-разделом и форматировался в NTFS со стандартным размером блока (4KB). Раздел делался размером 40GB, на нем создавался тестовый файл IOmeter (iobw.tst), размером 16GB (для гарантированного “пробоя кэша”). На каждой VM делался 4-процессорный vCPU, и, соответственно, запускались 4 Worker, на каждом из которых пускался тестовый паттерн на созданный диск, в 16 потоков ввода-вывода (Outstanding IOs) на каждый Worker, то есть 64 одновременных потока ввода-вывода на диски (контроллер NetApp). Загрузка хост-сервера тестом не превышала при этом 15% (мощная зверюга этот 3850), загрузка стораджа колебалась, но также не превышала 80%. То есть заведомо мы в “потолки” нигде не упирались.

Для минимизации эффектов “прогрева WAFL” (о котором еще будет пост, это также была одна из тем “исследовательской недели”) я делал длинный ramp-up (10 минут), а затем начинался собственно измеряемый тест, длиной 30 минут. Я брал для оценки значение в steady state, ближе к концу теста, и для оценки параллельно проверяемого эффекта “падения производительности” при прогреве – ближе к его началу.

Однако, перед исследователем, в моем лице, встала проблема: как обеспечить “фрагментацию” файла тестирования? Если создать последовательный, упорядоченный файл просто: запускай IOmeter на пустом диске – вот он и создаст свой iobw.tst, то с фрагментацией “на заказ” сложнее.

Для того, чтобы сделать фрагментированный файл я нашел любопытную утилитку, под названием MyDefragmenter, которая, как ясно из названия – дефрагментатор. Но у нее в комплекте есть также программка MyFragmenter :). Она делает вполне ожидаемую из названия вещь :)

Я взял созданный IOmeter тестовый файл и качественно замесил его с помощью этой утилитки. Я фрагментировал с ее помощью этот файл на 250 тысяч кусочков по 64KB каждый (ну, чтоб не было претензий, что гранаты у нас не той системы;), а потом повторно провел тестирование описанными выше паттернами.

Также я проанализировал ситуацию с фрагментацией не только файла на NTFS, но и в WAFL, а затем измерил эффект от работы reallocate в WAFL.

Хочу отдельно отметить, что в данном случае измеренные “попугаи”  не могут рассматриваться по абсолютной величине, я не проводил никакого (необходимого) тюнинга системы, и настройки ее “по уму” и по best practices (это я  сделаю позже, ту у меня есть некоторые бюрократические процедуры для этого). Целью теста было сравнить два достигнутых параметра производительности: “А” и”Б”, то есть их соотношение, а не достижение абсолютного рекорда, поэтому реплики с мест “чота как-то иопсев маловата!” мы отметем как неорганизованные ;).

Вот какие результаты я получил:

Continue reading ‘В последний раз о фрагментации файлов и производительности’ »

Так что же там на самом деле происходит с фрагментацией на NetApp?

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

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

Поэтому официальная позиция состоит в рекомендации, в случае, если влияние фрагментации в вашем конкретном случае, проявляется негативно (она, кстати, может и не проявляться), то включать wafl reallocate ( reallocate on / reallocate start [/vol/volname]) и спать счастливо.

Вообще же FUD вокруг non-contiguous wafl blocks allocation построен (впрочем, как и почти любой FUD) вокруг плохого представления технических деталей процесса и иногда чистосердечного, а чаще злонамеренного “непонимания” этих деталей. Давайте, для начала, разберем как же записываются данные в WAFL, по крайней мере на том уровне, на котором нам этот процесс показывает NetApp.

Но начать придется издалека.

Continue reading ‘Откуда вообще берется фрагментация?’ »

“Усилиями” наших конкурентов все нынешние и будущие пользователи 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]).

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

Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.

Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

В блогах я нашел описание любопытного эксперимента (по ссылке часть 5, смотрите в тексте ссылки на предыдущие 4 части).

Автор создавал сильно фрагментированный, кусками по 2MB и 128KB (5000 и 60000 кусков соответственно), файл, общим размером 10GB, и тестировал на нем последовательные чтения и записи. В качестве дискового хранилища использовались как диски самого сервера (на графиках - DAS), так и раздел на SAN-хранилище EMC Symmetrix DMX-2.

Вот как описывает тестовое оборудование сам автор: The server was a standard DL580 with 4 single-core sockets (2.0GHz Xeon) with 4GB of RAM. The disk array was a DMX2 with 10K rpm 146GB FC drives in a RAID10 config. The test LUN was 96GB in size (with 8GB disk slices from 24 spindles). Two Emulex LP8000 HBAs were load balanced with PowerPath.

Первый результат был обескураживающим. В случае использования высокопроизводительного SAN-стораджа, результаты для фрагментированного и дефрагментированного файла, и тестирования последовательной записи блоками по 1К,  были практически идентичными. Очевидно, что эффективное кэширование и хороший запас быстродействия DMX “съели” возможное снижение быстродействия из за присутствия фрагментов.

Далее автор создал аналогичный раздел на дисках серверов (DAS), и протестировал его.

?? тут мы уже видим значительный эффект от фрагментированности файла при последовательном доступе (почти 30% снижение быстродействия).

Далее автор уменьшил размеры “блоков фрагментации” до 128KB (то есть увеличил количество фрагментов своего 10GB тестового файла), и проверил эффект на последовательном чтении.

?? снова мы видим, что эффект хорошо заметный на DAS, практически отсутствует на высокопроизводительном SAN-массиве.

Проявляется ли хоть как-то эффект от фрагментации вообще? Автор обнаружил лишь один параметр:

На файле размером в 10GB, состоящим из 60 тысяч хаотически разбросанных по диску фрагментов заметно выросло время Latency, задержек чтения. Обратите внимание, что для такого же 10GB-файла с 2MB блоками, разбитого на 5000 таких же разбросанных фрагментов, не было даже и такого эффекта.

??, наконец, автор измерил время ряда операций:

В заключение этого поста я хотел бы особо обратить внимание читателя вот на что. Целью поста является не отрицание влияния фрагментации на производительность чтения-записи при последовательном доступе. Уверен, в любом случае можно подобрать такое сочетание режима доступа, размеров файла и блоков чтения, что этот эффект будет отчетливо проявлен.
Однако я хотел бы привлечь внимание читателей к тому факту, что, зачастую, негативный эффект фрагментации на производительность в реальной жизни, в вашем конкретном случае, и на современных производительных системах хранения, зачастую необъективно переоценивается и ей придается значительно больше значения, чем присутствует на самом деле.
??з приведенных результатов вы видите, например, что даже на последовательном, наиболее страдающем при фрагментации режиме, на высокопроизводительном сторадже влияние фрагментации, в случае конфигурации, тестируемой автором цитированного поста, практически ничтожно.

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

Алекс Макдональд, инженер NetApp, в своем блоге привел любопытную модель, оценивающую влияние фрагментации на эффективность, в случае случайного (random) по характеру доступа.

Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. ?? наконец он сравнил суммарное расстояние “seek” в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).

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

Несколько неожиданный для “здравого смысла” результат, однако, поразмыслив, нельзя не признать его правильным. “Случайное” помноженное на “случайное”  не дает “случайное в квадрате”. :)

Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество “вредоносного” seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

Любопытный отчет о тестировании систем NetApp с помощью iometer.
Подробно рассмотрены некоторые важные аспекты процесса, в том числе приведен паттерн, на которых проводилось тестирование (симулировалась загрузка типа производимой Exchange 2003).
В целом все довольно схоже с моими результатами, которые я делал в прошлом году, да и выбранная методика в целом похожа.

Часть 1.

Часть 2.

Тестировались FAS3070 и FAS2050.
Обратите внимание, что автор специально готовил фрагментированные разделы, чтобы приблизить результаты к реальным условиям эксплуатации.
??змерены и приведены результаты для различных показателей фрагментации.