about NetApp

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

Вопрос: А как понять величину фрагментированности? Это много, или мало? А если много, то что делать? ?? насколько оно влияет, если много?

Ответ: Давайте разберем по порядку.

В документации, в разделе, посвященном команде reallocate говорится:
reallocate measure [-l logfile] [-t threshold] [-i inter_val] [-o] pathname | /vol/volname

Запуск измерения реаллокации для LUN, больших файлов или томов.

threshold - порог, ниже которого LUN, файл или том считаются неоптимизированными (фрагментированными) достаточно, для того, чтобы запустилась реаллокация, величина от 3 (средне оптимизирован) до 10 (очень сильно неоптимизирован). Значение порога по умолчанию равно 4.

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

Но пока непонятно что же стоит за этой величиной, какой “физический смысл”?

Хочу еще раз привлечь внимание админов NetApp к существованию на NOW большой подборки техдокументации. NOW сегодня не такой плюшевый как, например, MSDN, но пользоваться можно.

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

Вот, например, статья в Knowledge Base
What do the the WAFL scan measure_layout ratio and measure_layout numbers mean?
“Что означают цифры measure_layout ratio и measure_layout при выполнении операции WAFL scan?”

Для Data ONTAP versions 6.5 и позднее

measure_layout ratio: Это отношение между числом записанных “чанков” (”chunks”, “кусков”) которые занял файл, и теоретическим минимумом числа таких чанков, которые были бы записаны для этой операции на полностью пустой файловой системе. Если ей ничто не помешает, то WAFL запишет данные в последовательные чанки размером 256 KB на каждый диск тома. Но если система не найдет куска последовательных 256 KB свободного места, то она запишет кусок меньшего размера.

measure_layout считает число чанков, в которые попали данные, и делит это число на их минимально необходимое количество. Таким образом наилучший возможный результат равен 1 (число записанных чанков равно числу минимально необходимых для размещения данных), а наихудшее - 64 (когда только один блок данных WAFL, равный 4 KB, попадает в каждый чанк). Основное оценочное правило, если том имеет 1/N свободных блоков (включая 10% WAFL reserve, служебного резервирования файловой системы под ее собственные структуры), то ожидаемая величина будет близка к N (на практике, обычно лучше). Пример (romx): Половина диска пусты (1/2), то следует ожидать величину rate до 2. Четверть (1/4) свободна - до 4.

Наихудшая возможная величина для систем с менее чем 3 GB RAM равна 16 (Sic! romx), исключая системы типа FAS250, FAS270 и FAS270c. Для этих систем наихудшая величина равна 64.

Не спрашивайте меня почему так, я просто разместил объяву я просто перевел статью в KB.

На практике вполне можно достичь значительных величин фрагментации, если поставить такую цель, например при тестировании, ссылку на статью о котором я давал раньше, человек создавал том с fragmentation rate равным 22. При этом, с помощью программы Iometer, в течении 6 часов проводилась непрерывная случайная запись в файл размером 100GB 64-мя одновременными потоками
При этом, ухудшение производительности на фрагментированном с величной rate: 10 (как называет эту величину документация по reallocate - very unoptimized) составило примерно 15 процентов.

Таким образом, наихудшего значения фрагментации для записываемых данных (не для уже записанных!) можно достичь интенсивно записывая на почти заполненный том, с объемом свободного пространства на нем менее 1/16 от общего пространства.

Если еще внимательно подумать над вышенаписанным, то становится понятно, что фрагментация вовсе отсутствует для данных, помещающихся целиком в один кластер-”блок” WAFL 4KB, он никогда не разбивается на части, и принципиально сравнительно невысока для записываемых файлов, размерами менее одного “чанка” - 256KB, так как если уж у нас есть последовательный кусок места в 256KB на диске, то данные будут записаны в этот кусок, целиком, без разбивки.

На следующей неделе мы продолжим “сеанс черной магии с последующим ея разоблачением”, и рассмотрим другие темы, поднимающиеся нашими коллегами-конкурентами, в отношении продукции NetApp.