about NetApp

Сегодня в переводах новый автор, это principal technologist регионального представительства NetApp по Австрали и Новой Зеландии, и директор SNIA ANZ - Richard J Martin. Его блог это вообще и в целом довольно отличающееся явление от, увы, распространенного сейчас стиля среди блоггеров “Так как мне не хватает 140 символов моего твиттера, я вынужден написать эти 320 символов в блог, но лучше читайте мой твиттер”, его записи в блог это, порой, настоящие глубокие статьи, которые интересно читать и трудно переводить.

Надеюсь, что он еще не раз появится в моих переводах.

Ричард Мартин, NetApp Australia отвечает на вопрос “как заполненность данными системы хранения влияет на ее производительность?”

How does capacity utilisation affect performance ?

September 10, 2011 storagewithoutborders

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

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

Поэтому, отвечая на вопрос, как уровень заполненности системы хранения влияет на ее производительность, мне приходится оговариваться, что "это зависит от ряда факторов", но в большинстве случаев, когда задают такой вопрос, то спрашивающего он интересует для нагрузки с высоким уровнем операций записи, например VDI, некоторые виды online transaction processing, и системы электронной почты.

Если вы рассматриваете такие варианты нагрузки, то можно смотреть наш старый добрый TR-3647 в котором как раз рассматриваются высокие нагрузки со значительными объемами записи, и где говорится:

Структура размещения данных WAFL, используемая в Data ONTAP, оптимизирует записи на диск, для улучшения производительности системы и повышения уровня использования полосы пропускания дисков. Оптимизация в WAFL использует небольшой объем свободного или зарезервированного пространства в пределах aggregate. Для высокой нагрузки, связанной с интенсивной записью, мы рекомендуем оставлять незанятым пространство, равное, в среднем, 10% от usable space, для работы этого оптимизационного процесса. Это пространство не только обеспечивает высокопроизводительную запись, но также работает как буфер при неожиданно возникающих потребностях приложения в свободном месте при объемных записях на диск.

Я видел некоторые бенчмарки, использующие синтетическую нагрузку, где точка перелома графика производительности наблюдалась между 98 и 100% usable емкости, после вычета WAFL reserve, я также видел проблемы производительности, когда люди полностью заполняли все доступное пространство на системе хранения, а затем начинали писать не нее мелкими блоками множество перезаписей данных. Это не является уникальным свойством именно WAFL, в случае любой системы хранения такое ее использование будет довольно плохой идеей, заполнить все пространство на любой структуре данных, а затем пустить на нее объемный random write.

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

Оставляя в стороне тему FUD, (подробный его разбор требует довольно глубокого понимания внутренней архитектуры ONTAP) при рассмотрении того, как влияет заполнение емкости на производительность на системах хранения NetApp FAS, надо хорошо понимать следующие моменты:

1. Для любого конкретного типа рабочей нагрузки и типа системы хранения вы можете достичь только сравнительно ограниченного числа операций на диск, это число на диск 15K RPM составляет, обычно менее 250.
2. Производительность системы хранения обычно определяется тем, на сколько дисков может быть распараллелена нагрузка ввода-вывода.
3. Большинство производителей систем хранения предоставляют для рабочей нагрузки ввода-вывода диски, объединенные в RAID-10, который использует вдвое больше raw-дисков на данный объем usable. При этом NetApp использует RAID-DP, который не требует удваивать количество дисковых шпинделей на заданный объем usable данных.
4. В большинстве бенчмарков (см. например SPC-1), NetApp использует для тестирования все доступное дисковое пространство, кроме 10% от usable space (в соответствии с написанным в TR-3647) что дает пользователю примерно 60% от емкости raw дисков, при этом достигая того же уровня IOPS/диск, которое другие производители получают при уровне usable в 30% от raw. Таким образом, равную производительность из расчет на жесткий диск мы обеспечиваем при на 10% большем уровне usable пространства, чем другие производители могут теоретически достичь при использовании RAID-10.

В итоге, даже без использования дедупликации и thin provisioning, или чего-то подобного, вы можете хранить вдвое больше данных на системе хранения NetApp FAS, обеспечивая тот же уровень производительности, как и большинство конкурирующих решений с RAID-10.

Хотя все это действительно правда, следует отметить, что тут есть и один недостаток. Хотя величина IOPS/Spindle более-менее та же, величина "плотности IOPS" (IOPS density) измеренная в IOPS/GB для результатов NetApp SPC-1 составляет примерно половину от решений конкурентов, (те же IOPS , 2x данных = вдвое меньше плотность). Хотя это на самом деле и сложнее сделать, за счет более низкого соотношения cache/data, если у вас есть приложение, которое требует очень высокой плотности IOPS/GB (например некоторые инфраструктуры VDI), тогда вы можете не использовать всю имеющуюся у вас дополнительную емкость под эту нагрузку ввода-вывода. Все это дает вам, в результате, возможность выбора из трех вариантов.

1. Не использовать это дополнительное место, оставив его незанятым на aggregate, позволить работать на нем оптимизации записей и получить лучшую производительность.
2. Использовать дополнительное место, например для данных некритичных к производительности, таким как хранение снэпшотов, или зеркальная реплика данных, или архивы, и так далее, и установить этой нагрузке пониженный приоритет с помощью FlexShare.
3. Установить карту Flash Cache, которая удвоит эффективные показатели IOPS (зависит от вида нагрузки, конечно) на физический диск, что обойдется дешевле, и сэкономит ресурсы, чем удвоение количества физических дисков.

Если вы поступаете иначе, то вы можете получить ситуацию, когда наша высокая эффективность использования пространства позволяет пользователю запустить слишком большую нагрузку по вводу-выводу на недостаточном количестве физических жестких дисков, и, к сожалению, снова снова порождает пресловутый и бесконечно гуляющий FUD о "Netapp Capacity / Performance".

Он некорректен прежде всего потому, что причина тут не в каких-то тонкостях Data ONTAP или WAFL, а в том, что на систему, сайзинг которой был проведен для рабочей нагрузки X, помещают 3X данных, так как "на дисках еще есть место", и весь ввод-вывод этих 2-3-кратного объема данных наваливается на дисковые шпиндели, запланированные под совсем другой уровень нагрузки и объемов.

Для того, чтобы сделать счастливыми, и, что немаловажно, поддерживать это состояние в пользователях вашей системы хранения, вам, как администратору, нужно уметь управлять не только доступной вам емкостью, но и доступной производительностью системы хранения. Чаще всего у вас будет исчерпываться одно раньше, чем другое, и работа эффективной IT инфраструктры означает умение балансировать рабочую нагрузку между этими двумя ресурсами. В первую очередь это означает, что вы потратили определенное время измеряя и мониторя емкость и производительность вашей системы. Кроме этого вам следует настроить вашу систему так чтобы иметь возможность мигрировать и ребалансировать нагрузку между ресурсными пулами, или же иметь возможность легко добавлять дополнительную производительность для имеющейся нагрузки не прерывая нормальной работы системы, что может быть осуществлено с помощью таких технологий, как Storage DRS в vSphere 5, или Data Motion и Virtual Storage Tiering в Data ONTAP.

Когда вы наблюдаете за параметрами вашей системы хранения, вы можете своевременно принять меры, до того, как какие-либо проблемы проявятся. У NetApp есть множество великолепных инструментов по мониторингу производительности всей системы хранения. Performance Advisor дает вам визуализированные и настраиваемые алерты и пороги их срабатывания для встроенных метрик производительности, доступных в каждой системе хранения FAS, а OnCommand Insight Balance предоставляет углубленный отчет и упреждающий анализ для всей вашей виртуализованной инфраструктуры, включающей, в том числе, и стороннее, не-NetApp, оборудование.

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

Хотя я понимаю весь соблазн вернуться к старой практике, привычной для "классических" систем хранения, когда для системы хранения почти нет шансов превысить ее возможности по IOPS, прежде чем она исчерпает свои возможности по емкости, это почти всегда невероятно расточительно, и ведет, по моему опыту, к уровню использования емкости около 20% и менее, и приводит к экономически неоправданной цене/GB для таких “Tier-1″ хранилищ. Возможно еще настанут "сытные годы", когда администраторы будут снова иметь роскошь не обращать внимания на цену решения, или, быть может, вы окажетесь в такой редкой отрасли, где "цена не имеет значения", однако для остальных нынешние времена - времена начистить и привести в готовность свои навыки мониторинга, настройки и оптимизации. Сегодня спрос есть на умение делать больше с меньшими затратами, и надо учиться этому.

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения NetApp – WAFL online compression, то есть сжатия данных “на лету”, для хранения их на диске в сжатом виде. В настоящий момент блоки, которые были компрессированы таким образом, не кэшируются в Flash Cache / PAM.

Как вы знаете, у NetApp есть сейчас две основных технологии снижения storage footprint, то есть объемов хранения, занимающих физическое дисковое пространство, это давно существующая и хорошо себя зарекомендовавшая во многих случаях дедупликация, и появившаяся сравнительно недавно онлайн-компрессия. Две эти технологии существуют и работают независимо друг от друга, и даже дополняют друг друга. Каждая из них имеет свои предпочтительные области применения. Например, дедупликация хорошо работает для сред виртуализации, где ее эффективность (величина экономии после ее применения) может достигать 70-85% от первоначально занятого на дисках, но в рядя других применений, например для баз данных, ее эффективность (по разным причинам, на которых мы не будем сейчас подробно останавливаться) значительно ниже, часто не более 10-20%.

Напротив, компрессия довольно неплохо уменьшает объем хранения для пользовательских файлов и баз данных (35-50%). Она также сравнительно неплохо работает даже и на уже дедуплицированных данных, что может еще повысить результаты экономии.

Сравнительно неплохая эффективность компрессии на датасетах типа баз, например, может натолкнуть вас на мысль использовать компрессию для ваших баз данных, на системах, которые часто используют Flash Cache для повышения производительности работы. Но тут вот стоит принять во внимание момент, который я вынес в заголовок заметки: Блоки, которые располагаются на томе, с включенной компрессией, и подверглись компрессии, не кэшируются во Flash Cache.

Это диаметральным образом противоположно ситуации с дедупликацией, так как дедуплицированные блоки, напротив, попадают в dedupe-aware кэш, который знает о их дедуплицированности, и умеет ее использовать (например блок, на который на диске имеется десять ссылкок из десяти разных VMDK, будет считан и находиться в кэше не в 10, как в традиционной форме кэширования, а всего в одном экземпляре, что, очевидно, увеличивает эффективную емкость кэша).

Если у вас система с Flash Cache, и вы одновременно собираетесь использовать компрессию для данных – то будьте внимательны. Компрессированные тома в системе с Flash Cache могут иметь значительно отличающуюся от некомпрессированных производительность, за счет того, что с некомпрессированными томами работа будет идти через Flash Cache, а с компрессированными – нет. Эта разница, не слишком заметная для систем без Flash Cache, за счет такого поведения для систем с Flash Cache, может быть неприятным сюрпризом.

Эта особенность работы компрессии описана в новом TR-3958 Compression and Deduplication for DataONTAP 8.1 operating in 7-Mode на странице 22:

7.6 PAM AND FLASH CACHE CARDS

In environments with high amounts of shared blocks that are read repeatedly, the PAM or Flash Cache card can significantly reduce the number of disk reads, thus improving the read performance. The PAM or Flash Cache card does not increase performance of the compression engine or of reading compressed data. The amount of performance improvement with the PAM or Flash Cache card depends on the amount of shared blocks, the access rate, the active dataset size, and the data layout. The PAM or Flash Cache card has provided significant performance improvements in VMware® VDI environments. These advantages are further enhanced when combined with shared block technologies, such as NetApp deduplication or NetApp FlexClone® technology.

Так что обратите внимание на этот момент, и не применять компрессию для томов, производительность которых для вашей задачи критична, и которые вы планируете ускорить с помощью Flash Cache

UPD: Попросили уточнить. По-прежнему кэшируются во Flash Cache НЕсжатые блоки на сжатом томе (например, если эти блоки были исключены из процесса сжатия в результате плохого compression rate на этапе estimate для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

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

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.

Так что же там на самом деле происходит с фрагментацией на 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]).

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

В блоге Vaughan Stewart была найдена интресная картинка:

Да, это то что вы подумали. Начиная с Data ONTAP 7.3.3 и 8.0.1 на WAFL теперь работает компрессия (лицензия бесплатна, как iSCSI, или дедупликация, например), причем использование компрессии не отменяет и не заменяет, и может использоваться как совместно с дедупликацией, так и по отдельности. Это такая же знакомая и привычная онлайн-компрессия как на NTFS, например.

Компрессия пригодится в случаях, когда на диске лежат различные по содержимому данные, но не слишком дублирующиеся внутри на уровне 4KB-блоков WAFL. Тем не менее содержимое этих файлов вполне может сжиматься классическими LZ-алгоритмами. Например у меня на ноутбуке папка Program Files диска C: сжата почти на 30% от ее, примерно 2GB, объема.
Хороший пример – homedir различных пользователей организации. Хотя в хоумдирах иногда и попадаются идентичные документы и файлы у разных людей, в основном же, как показывает практика, большая часть содержимого хоумдиров достаточно уникальна, и не слишком эффективно дедуплицируется. Однако вполне поддается традиционному zip-like сжатию с неплохими показателями.

Для 7.3.3 компрессия идет как PVR, то есть доступна по запросу, но запланирована как стандартная опция в 8.0.1, которая выйдет этой осенью.

Возможно вы уже знакомы с так называемым special boot menu, которое появляется, если при загрузке с сериальной консоли нажать Ctrl-C. Любопытно, что кроме 6 предлагаемых вариантов, в этом меню есть и скрытые варианты. Например, если туда, вместо предлагаемых номеров, ввести WAFL_check [aggrname], где [aggrname] это имя соответствующего аггрегейта, то начнется подробная проверка консистентнсти WAFL на нем. Это может помочь если, по какой-то причине, состояние дисков и WAFL на них настолько нарушено, что система хранения не загружается, или не в состоянии разрулить проблему обычными средствами.

По сути это аналог fsck в single mode для привычных unix-type filesystem.

Пример:

Special boot options menu will be available.
NetApp Release 7.0.4P1: Mon Feb 27 14:36:15 PST 2006
Copyright (c) 1992-2006 Network Appliance, Inc.
Starting boot on Sat Mar 24 15:36:18 GMT 2007
(1) Normal boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Initialize all disks.
(4a) Same as option 4, but create a flexible root volume.
(5) Maintenance mode boot.
Selection (1-5)? WAFL_check aggr01
Sat Mar 24 15:38:15 GMT [wafl.vol.inconsistent:ALERT]: Aggregate aggr01 is inconsistent. Please contact NetApp Customer Support.
Sat Mar 24 15:38:15 GMT [raid.vol.replay.nvram:info]: Performing raid replay on volume(s)
Sat Mar 24 15:38:15 GMT [raid.cksum.replay.summary:info]: Replayed 0 checksum blocks.
Sat Mar 24 15:38:15 GMT [raid.stripe.replay.summary:info]: Replayed 0 stripes.
Checking aggr01…
WAFL_check NetApp Release 7.0.4P1
Starting at Sat Mar 24 15:38:17 GMT 2007
Phase 1: Verify fsinfo blocks.
Phase 2: Verify metadata indirect blocks.
Phase 3: Scan inode file.
Phase 3a: Scan inode file special files.
Phase 3a time in seconds: 9
Phase 3b: Scan inode file normal files.
(inodes 5%)
(inodes 10%)
…
(inodes 92%)
(inodes 97%)
(inodes 99%)

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

Несколько слов о том, почему, собственно, именно NetApp занял сейчас такую значительную долю рынка дедупликации, и что мешает сделать то же самое другим вендорам.
Ну конечно, в значительной мере, свою роль сыграло бесплатное предложение данного функционала, как я уже говорил ранее, лицензия на Deduplication поставляется бесплатно. И это, безусловно, способствовало широкому распространению технологии. Та же история была сыграна в свое время с рынком iSCSI, на котором NetApp так же занял значительную его часть (увы, не в России, которая до сих пор для себя iSCSI и его преимущества, по существу, не открыла)

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

А дело вновь в “волшебных пузырьках”, которые называются WAFL. :)

Один из блоггеров NetApp, за которым я внимательно слежу и читаю все его выпуски, уже не раз тут упомянутый Костадис Руссос, полемизируя с “блогорупором EMC” Чаком Холлисом, который использовал в одном из постов в приложении к продуктам EMC слова “Настоящий FibreChannel” (Real FibreChannel), в противовес “всяким там эмуляциям, SAN-ам из NAS-а, и прочим ‘виртуальным’ стораджам”, стал использовать термин “Лучше Чем Настоящий FibreChannel” (Better Than Real FibreChannel).

Итак, чем же NetApp Лучше Чем Настоящий FibreChannel.

Вы уже знаете, что система хранения NetApp для организации и доступа к данным на дисках использует специальную логическую структуру, особую “файловую систему”, под названием WAFL - Write Anywhere File Layout. К подробностям о ней, ее устройстве и всяких интересных штуках, отсылаю к моим предыдущим постам на эту тему.
Для нас сейчас интересен один аспект.

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

Это настоящий кошмар для любого “класического стораджа”, который любой ценой стремится минимизировать random-компоненту доступа, так как на нем эффективность его резко падает как на записи (особенно), так и на чтении (большое “замусоривание” кэша и отсутствие эффективного “предсказания”/”read ahead”).

Но ведь вспомните, такой режим “постоянно-рандомной записи и чтения” есть по сути “нативный” режим для WAFL! Блоки WAFL записываются и считываются произвольно и рандомно не только в случае дедуплицирования данных, но и при обычной, естественной работе, которой стораджи NetApp занимаются уже много лет!
То есть переход от “классического” к “дедуплицированному” хранилищу, и вызванная этим “фрагментация данных”, такая катастрофическая для “классического” стораджа, вполне обычна и повседневна для NetApp, и включение дедупликации на быстродействии системы хранения никак не отразится!

Что, кстати подтверждают и реальные пользователи, которые называют величины падения производительности при переходе к дедуплицированным данным, там где их удается замерить, в считаные единицы процентов.

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

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

Костадис Руссос (http://blogs.netapp.com/extensible_netapp/2008/10/why-wafl-is-not.html)
Мой перевод оригинального авторского текста.

Что такое WAFL: Введение

Многие годы потенциальные пользователи NetApp находятся в плену мистификации о взаимоотношениях между WAFL и SAN. В частности, правда ли, что LUN у NetApp это файл, лежащий на файловой системе?
Для меня, работавшего над NetApp много лет, вопрос всегда казался странным, так как мой опыт говорит, что WAFL есть то, что предоставляет средства и методы для построения файловой системы, но при этом она не файловая система как таковая.

Моим первым проектом в NetApp было создание медиакэша для кэширования потокового контента с использованием WAFL (проект NetCache). И для нас WAFL был только способом перемещать данные на диск и с диска, а также способом записывать наш формат хранения на диск, но это была, конечно, не файловая система. Для официального описания решения смотрите наш патент.

Предположим, что файловая система имеет определенные правила, согласно которым вы получаете доступ и находите объекты, которыми она управляет. Обычным образом вам надо сначала просмотреть директорию, затем открыть файл, и после этого читать или писать в файловый хэндл, переданный вам файловой системой. WAFL не накладывал таких ограничений на наш проект. Мы могли непосредственно писать или читать из объекта. Мы были свободны использовать любую схему поиска, какую мы хотели.
Как конкретный пример, когда мы обрабатываем кусок медиапотока, мы должны использовать некий хитрый хэш для нахождения объекта на диске, без необходимости делать поиск его по имени, эффективно обходя обычные методы просмотра директорий.

Что WAFL обеспечивает, так это механизм для отслеживания всех дисковых блоков. Кроме этого, WAFL управляет свободным местом. WAFL также отвечает за то, чтобы все данные были записаны на диск надежным образом.

Но когда мы захотели использовать WAFL как обычную файловую систему, мы обнаружили, что она не предоставляет необходимых интерфейсов. Например, WAFL не имеет механизмов для обработки операций открытия и закрытия. Еще сильнее мешало то, что WAFL был оптимизирован для операций чтения и записи блоками по 32kB и 64kB, а не для записи, например, 12 байт.

При создании нашего продукта мы закончили тем, что использовали целую кучу механизмов WAFL для построения нашего собственного специализированного хранилища данных, оптимизированного для задач потокового медиа. Во время всей этой работы, WAFL никогда не воспринималась нами как файловая система. Как набор неких средств и «примитивов», которые делали возможными то, что мы придумали, да, но определенно не как файловая система.

Таким образом, мой личный опыт состоит в том, что создать поверх WAFL высокопроизводительную файловую систему довольно просто, но сама WAFL не является файловой системой.  
Однако, принимая во внимание тот факт, что наш основатель, Dave Hitz, назвал WAFL файловой системой, наши патенты, а также множество упоминаний в статьях называют ее файловой системой, я решил рассказать о своей точке зрения на этот вопрос.

Что такое «файловая система»?

В соответствии с определением Википедии:

A file system is a special-purpose database for the storage, hierarchical organization, manipulation, navigation, access, and retrieval of data.

«Файловая система это специализированная база данных, для хранения, иерархической организации, управления, навигации, доступа и извлечения данных»

Это на самом деле очень хорошее определение. Проблема в том, что оно слишком широко. Я считаю, что определение файловой системы также должно указывать на то, как мы ее используем.
Мы ожидаем, что файловая система использует такие операции, как открытие, чтение, запись и закрытие, применимое к файлам. Мы ожидаем, что файлы имеют определенные метаданные, такие как имена, списки контроля доступа (ACL), их время доступа и создания. Мы ожидаем, что прежде чем мы откроем файл, мы должны пройти по структуре директорий. Мы ожидаем, что структура директорий будет древовидным графом.

И поверх всего этого, каждая файловая система имеет дополнительные правила и семантику, которая указывает, как осуществляется доступ к файлам, и как обеспечивается управление иерархией директорий
Мой первый поверхностный взгляд показал, что для пользователя файловой системой является не WAFL, а NFS или CIFS.  Семантика, и то, как к файлу организуется доступ, как он управляется и используется, определяется протоколом NFS. NFS это распределенная файловая система, которая имеет такой компонент, как сервер файловой системы, но также дополнительные компоненты, такие как сервисы аутентификации, которые не являются частью сервера файлов. Это также верно и для CIFS.
Ну, вопрос закрыт, правда? Но это было слишком примитивно, чтобы меня удовлетворить. 
И мне захотелось пойти в вопрос глубже.

Попробуем другой путь добраться до сути вопроса.
Давайте определим, что файловая система должна иметь следующие элементы:

1. Методы, позволяющие воздействовать на файлы
2. Методы, позволяющие воздействовать на директории
3. Методы для сохранения данных на диск
4. Методы для извлечения данных.
5. Структуры данных, для сохранения данных на диске
6. Правила того, как можно найти файлы.

Кроме того, давайте согласимся, что современные системы хранения также имеют следующие элементы:

7. Методы для организации физических дисков в большие массивы
8. Методы разбиения физического пространства такого массива на меньшие логические разделы

Давайте сфокусируемся на пунктах номер 1, 2 и 6

В частном случае WAFL, что является файлом, или что директорией, определяется распределенной сетевой файловой системой, частью которой является WAFL. И задолго до того как я занялся темой, пришел в компанию, и даже раньше, чем я вообще услышал про существование Data ONTAP, более умные люди чем я нарисовали следующие любопытные структуры:

Они просто создали некие обобщенные наборы примитивов, поверх которых может быть наложена семантика NFS и CIFS. Семантика NFS и CIFS, которая является частью стека протоколов, а используемые примитивы - часть WAFL. Так, даже на своей ранней стадии развития, WAFL предоставляла механизмы для хранения файлов и директорий, без подразумевания семантики таких операций.

Фактически, правило того, каким образом ищется файл, определяется тем, как NFS-клиент ищет этот файл, а не тем, как работает Data ONTAP.

В этом документе про Data ONTAP GX ведется дискуссия в главе 5 об таком разделении, в контексте протокола Spin NP. Хотя это и дискуссия вокруг GX, там поддерживается многое из того, о чем я говорю здесь.

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

Теперь давайте посмотрим на пункты 3 и 4.

Иерархическое представление данных значительно развилось за 20 лет. Когда я еще учился в колледже, файловые системы отвечали только за disk layout, так как OS сами знали, где размещены те или иные блоки данных. Сегодня, с LUNами, многие файловые системы по прежнему находятся в плену таких иллюзий, но, в реальности, физическое размещение блоков для них тайна. Гений Хитца и Лау был в том, что они разработали WAFL на основе идеи, что WAFL сама по себе не управляет физическим размещением дисковых блоков, вместо этого им занимается более нижний, уровень RAID.

Не секрет, и это понятно, что ONTAP RAID настроен для работы именно с WAFL. Они вообще очень хорошо согласованы между собой. Конечно в наше время почти каждая файловая система работает поверх того или иного уровня RAID, но только WAFL с ONTAP RAID знают друг о друге достаточно, чтобы использовать  при работе преимущества друг друга.

Но вопрос был, является ли WAFL файловой системой, ну, допустим в ней есть что-то из нашего пункта 3 и что-то из 4, но очень многое зависит от чего-то, лежащего за пределами WAFL, чтобы делать вещи, традиционно лежащие в области деятельности файловой системы.

А что насчет пунктов 7 и 8?

Сегодня большинство разработчиков файловых систем рассматривают систему управления томами (volume manager (8)) и менеджер логических томов (logical volume manager (7)) как внешнюю часть по отношению к файловой системе. Например, Symantec явно разделяет свой volume manager, vxvm и файловую систему vxfs.

Но в NetApp, WAFL это одновременно и volume manager и logical volume manager.

Что там осталось, номер 5?

И тут – да, дисковые структуры это все структуры данных WAFL. И это важный момент. Так как WAFL это один, единый для всех вышележащих средств формат дисковой структуры, то файловые операции NFS и CIFS могут работать с одними и теми же дисковыми объектами.

Ну, так что же такое WAFL?

Это то, что предоставляет средства для построения семантики файловой системы, то, что управляет дисковыми структурами организации блоков данных, а также блоками свободного места, и выделяет среди них место под размещение новых блоков данных на диске, и, кроме этого, работает как менеджер физических и логических томов (volume manager).

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

SAN и WAFL

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

Тот факт, что WAFL поддерживает SAN (Storage Area Network), и то, как именно она поддерживает SAN, по-моему, является наиболее существенным аргументом.

Но короткое отклонение: Что такое LUN?

Ключевое, базовое определение LUN это «логическая организация дисковых блоков». Логическая организация дисковых блоков требует некоторых дисковых структур данных. И оказалось, что дисковые структуры, которые используются для организации и размещения на диске файлов, можно также использовать для организации и размещения LUNов.
Однако из того факта, что находящаяся на диске структура хранения, которая организует дисковые блоки, та же самая что и для файлов, не следует, что доступ к LUN осуществляется, или работа с ним происходит как с файлом.

LUN и WAFL

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

Однако не иллюстрируется на этой схеме то, что, кроме этого, существует некоторая специальная оптимизация в части процессов чтения и записи, для того, чтобы получить уровень производительности, какой и ожидают получить пользователи SAN.

Поскольку нижележащие структуры данных, используемые для чтения с дисков, те же самые, что используются, например, NFS для манипуляций с данными, то наблюдается интересный «побочный эффект»: клиент NFS (или CIFS) видит LUN в виде файла. Но вспомните, что хотя NFS и получает доступ к LUN, это происходит совсем иным способом для системы, нежели ее нормальный доступ к LUN в SAN. То есть объект на диске становится для вас файлом, только когда вы приходите к нему через NFS-стек, но не через обычный для него путь доступа, как к собственно LUN.

Если вы знакомы с разного рода объектными языкам программирования, то вы поймете нарисованную диаграмму:
 

Вы видите, что inode это дисковый объект, что LUN это inode, и что FILE это inode, но LUN это НЕ FILE.

Ладно, каков же вывод?

Вывод в том, что WAFL это часть кода, который обеспечивает механизмы «чтения или записи на диск» как для NFS и CIFS, так и для SAN. Семантика того, как обеспечивается доступ к блокам, предоставляется более высокоуровневым кодом, который частью WAFL, не является, и значит WAFL это не «файловая система».

Где же причины ошибочного восприятия?

Оптимист во мне думает, что причина столь распространенной ошибки в отношении WAFL и SAN в том, что NetApp не описал и не объяснил достаточно подробно схему ее структуры (layering). И что без такого описания, вполне логично было бы представлять это в следующем, полностью неверном виде: 

Или, используя мою объектную диаграмму 
 
Что, якобы, файл это inode, и LUN это файл.

Таким образом, WAFL это не файловая система. WAFL это некие средства и методы, предоставляющие возможность с помощью них различным файловым системам и технологиям получать доступ к блокам на диске. Эти средства и методы WAFL обеспечивают лидирующую в отрасли производительность, но вместе с тем и гибкость использования любых наших data management primitives, не идя на компромиссы в отношении скорости работы.

Как обещал ранее, даю ссылку на переведенный документ по внутреннему устройству WAFL (Write Anywhere File System). Оригинал был опубликован в конце 1994 года в журнале USENIX, и, по сути, это то, с чего NetApp начался как идея, и как компания.
В основе всех устройств NetApp (ну разве кроме систем потокового шифрования Decru, и Virtual Tape Libraries (VTL) относительно недавно купленных ими) лежит эта “файловая система”, хотя правильнее было бы называть ее “файловая структура”, file layout.

http://www.netwell.ru/production/techbiblioteka.php

Чем по сути отличается File System от File Layout, почему эта разница так важна, как так получилось, что система, задуманная изначально как файловый сервер (NAS) без особых затруднений вскоре стала работать и как блочное SAN-устройство - об этом вы узнаете в нашей следующей серии :)