about NetApp

Несколько постов назад, в комментах, разгорелась нешуточная дискуссия о том, можно ли считать Flash Cache “истинно православным” средство tiering-а, и ставить его в ряд с множеством других аналогичных средств, например с EMC FAST.
Для разъяснения моей позиции на этот счет я и написал этот пост.

Для начала давайте определим что такое tiering вообще.

Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое) принято называть механизм перемещения данных между “уровнями” (tiers) хранения, характеризующимися теми или иными свойствами, например ценой, быстродействием, защищенностью, и так далее. Обычно tiering-ом принято называть механизмы, для перемещения данных между дисками разных типов, или дисками и магнитными лентами, или же ROM-хранилищем, часто он используется для организации ILM – Information Lifecycling Management – хранилища данных в соответствии с их статусом и уровнями QoS.

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

Что есть tiering с точки зрения приложения или пользователя? Зачем мы его применяем?

Целью tiering-а для пользователя является возможность повысить эффективность (в первую очередь экономическую) использования его системы хранения. Когда “цена значения не имеет”, то все просто – надо купить Symmetrix. Однако в реальной жизни цена очень даже имеет значение, и пользователь вынужден идти на компромиссы между ценой решения и необходимой пользователю производительностью.

Используемые в системах хранения диски сегодня имеют различную производительность, емкость и цену, причем производительность и емкость обычно величины обратно пропорциональные: больше емкость – меньше производительность (SATA), меньше емкость – выше производительность  (SAS), еще выше производительность и цена, и меньше емкость – Flash. Система хранения-же целом характеризуется соотношением IOPS/$, то есть количества единиц производительности с “вложенного доллара”.  Повысить этот параметр стремится любой вендор и любой покупатель системы хранения.

Согласно широкоизвестному Закону Парето (“20 процентов сотрудников делает 80 процентов всей работы”) сравнительно небольшая часть данных ответственна за значительную долю быстродействия системы. Напротив, значительная часть данных относится к так называемым “холодным”данным, скорость доступа к которым в принципе не критична.
Было бы неплохо, если бы эти 20% активных данных, скорость доступа к которым напрямую влияет на общую производительность, располагались на максимально быстром разделе хранилища, пусть он дорогой, но его емкость будет всего 20% от емкости хранилища, зато прирост мы получим во все 80%!

Именно эта идея лежала в основе идеи tiering-а. Если этот тип данных – активный, то автоматически перенесем его на более дорогие и быстродействующие диски, и повысим производительность доступа к ним, а менее активные данные – перенесем на менее производительные дешевый тип дисков. И настанет счастье, в виде повысившегося соотношения IOPS/$.

К такому, “классическому” типу tiering-а относится продукт EMC FAST – (Fully-Automated Storage Tiering). Он позволяет прозрачно для пользователя переносить фрагменты его данных между “уровнями” хранилища, например между разделами на дисках SAS и SATA.

Увы, дьявол кроется в деталях, и “всегда читайте написанное мелким шрифтом”. Первая версия FAST была весьма сырой, например, позволяла переносить только LUN-ы целиком, что, очевидно, неприемлемый на практике уровень “гранулярности” данных. Только в FASTv2 появилась возможность суб-LUN-овой миграции, впрочем, по-прежнему, мигрируемый минимальный фрагмент данных весьма велик (1GB!), да и еще окружен множеством ограничений использования (не поддерживается компрессия для данных, которые подлежат миграции, например).

К тому же, к сожалению, принадлежность данных к той или иной группе не фиксирована. Так, бухгалтерские проводки за прошлый квартал могут лежать “холодными”, до момента составления квартального или годового отчета, когда обращение к ним резко увеличится. Значит пока мы не распознаем и не смигрируем ставшие активными данные на быстрое хранилище, мы рискуем значительно терять в быстродействии, а если наш алгоритм выявления активных данных не обладает достаточным быстродействием, мы рискуем и вовсе не получить прироста, если “пики” доступа окажутся менее “разрешающей способности” анализирующего алгоритма, и не будут им распознаны как активность. Это же относится и к “устойчивости к помехам”, так, например, регулярный бэкап может свести с ума алгоритм анализа активности, ведь к данным обращаются каждую ночь!

Как вы видите, внешне очевидная и тривиальная задача анализа активности данных и переноса в соответствии с ними на те или иные типы дисков, обрастает сложностями.

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

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

Во-вторых, в область дорогого, но высокопроизводительного хранения – “кэша” – попадают “по определению” только “горячие” данные. Место в кэше всегда занимают только данные, к которым сейчас идет активное обращение. Все 100% дорогостоящего объема кэша используются для повышения производительности системы, а не просто “хранения”. Следствием этого является более высокая эффективность работы кэша. Процессор Intel Xeon имеет всего 8Mb кэша, что не мешает ему работать с в тысячи раз большими объемами ОЗУ на сервере, и, за счет этого, сравнительно небольшого, по относительной величине, кэша, эффективно ускорять доступ к размещенным в обширной памяти данным.

В третьих – процесс ускорения доступа и улучшения результата IOPS/$ путем кэширования есть, с алгоритмической точки зрения, процесс тривиальный. А раз так, он имеет минимум побочных эффектов и ограничений использования, а работать (и давать результат в виде повышения производительности) начинает сразу же, а не когда накопится статистика использования и, наконец, в соответствии с ней произойдет миграция данных с одних дисков на другие.

Минусы? Ну как же в нашей жизни и без минусов. Эффективность кэша, действительно высокая при чтении, сильно падает на операциях записи. Ведь если мы изменяем данные в их копиях в кэше, нам надо регулярно и своевременно обновлять их непосредственно по месту их размещения (этот процесс имеет название “сброса содержимого кэша” или “flush”). Значит, если мы изменяем содержимое блока, нам надо это изменение распознать и переписать его содержимое в основном хранилище, чтобы, когда блок будет вытеснен по неактивности из кэша, его новое, измененное содержимое не потерялось. Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.

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

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

Вот почему я считаю, что как EMC FAST, так и EMC FASTcache и NetApp FlashCache, все они являются формами организации tiering-а, и их можно рассматривать вместе, как формы одного решения.

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

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

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

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

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

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

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

В новых Software Bundles, которые приходят новым покупателям систем NetApp часто включены лицензии на SnapVault (пример – Windows Bundle для распродажных FAS2020, о которых я писал ранее). Однако, к сожалению, всё еще не все хорошо представляют себе как это работает, как может применяться, и чем может быть полезно.

SnapVault это средство D2D Backup для систем хранения NetApp (а в случае использования Open Systems SnapVault – OSSV – и для обычных серверов), использующее их возможности по созданию и удаленному хранению снэпшотов.

Как вы знаете, в отличие от всех прочих систем хранения, использующих то, что у них также называется “снэпшоты”, NetApp не только не возражает, но даже поощряет хранить снэпшоты долговременно, непосредственно на дисках. Дело в том, что хранение снэпшотов на дисках, как своеобразной локальной “резервной копии”, вместе с собственно данными, не приводит к падению производительности всей системы хранения, как это происходит с COW (Copy-On-Write) “снэпшотами”. Поэтому на всех системах, кроме NetApp, снэпшоты используются лишь как “временное хранилище” состояния данных. Создали снэпшот в ночной тиши слабозагруженного датацентра, быстро слили на ленты или другое архивное хранилище, и скорее удалить.

Не все йогурты снэпшоты одинаково полезны. :)

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

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

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

Было бы неплохо и копировать снэпшоты наружу как-то “по-снэпшотному”, сохраняя эту их эффективность использования места.
Именно это и делает SnapVault.
SnapVault – это способ хранить снэпшоты рабочих данных на внешнем хранилище, но “по-снэпшотному”, экономя пространство хранения.

Лицензии на SnapVault существуют в двух “ролях”. Одна называется SnapVault Primary, а вторая – SnapVault Secondary.

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

SnapVault Secondary – это лицензия, устанавливаемая на получателя резервных копий. На систему, которая хранит резервные копии от одной или нескольких SnapVault Primary систем.

В качестве SnapVault Primary может также работать так называемый Open Systems SnapVault (OSSV) – программный продукт (его для NetАpp написала компания Syncsort), устанавливаемый непосредственно на сервера под управлением Windows/Linux/etc и позволяющий им играть роль SnapVault Primary систем, делать на них снэпшоты (разумеется с определенными ограничениями, присущими то или иной OS), передавать их на хранение на систему SnapVault Secondary (В роли SV-Sec может быть только NetApp, нет OSSV Secondary), и восстанавливать их с таких снэпшотов, при необходимости.

Как и для чего можно применить SnapVault?

Например можно централизованно хранить резервные копии данных от множества отделений основного бизнеса, где, очень часто, нет достаточного бюджета и ресурсов для организации полноценного бэкап-решения. В случае использования SnapVault вам нужно только раз настроить расписание на удаленных системах и политики хранения резервных копий на центральном хранилище (это может быть выделенная система, или же пространство на основной системе хранения NetApp головной компании, с лицензией SV-Secondary на ней. А с использованием OSSV это можно делать и без систем NetApp в качестве Primary. И в дальнейшем резервные копии от всех систем будут автоматически, по расписанию, приходить на ваше хранилище с ролью SV-Secondary в главном датацентре.

При этом только в первый раз будет передан полный объем хранения (так называемая baseline copy) для создания первоначального “снимка”, в дальнейшем через каналы передачи данных будет передаваться уже только “разностная” информация, например только измененные за день работы блоки данных.
Допустим, что общий объем данных на вашей удаленной системе хранения равен 100GB. Но в течении суток меняется только около гигабайта.
Тогда при первом, baseline transfer, будет передано все 100GB (это можно сделать, например, локально, перед тем, как отвезти систему хранения в удаленный офис), а затем, при ежедневном копировании, будет передаваться всего 1GB. И целый месяц ежедневных резервных копирований полной системы на Secondary-системе в центральном офисе займет всего около 130GB.

Также можно использовать SnapVault и для организации удаленной копии данных для Primary-системы для “квази-DR” решения. При этом в качестве резервного хранилища для мощной SnapVault Primary может служить недорогая и с невысокой производительностью, достаточной только для приема и хранения реплики данных, система с лицензией SnapVault Secondary.

Совместно и интегрированно с NetApp SnapVault могут работать такие программные продукты, как CommVault Sympana Suite и Syncsort Backup Express.

Настраивать и управлять работой SnapVault можно как из командной строки, так и с помощью отдельного программного продукта NetApp – Protection Manager, который также сейчас поставляется в составе многих бандлов, например в ONTAP Essential для FAS3200/6200.

Наилучший способ углубиться в тему – прочесть TR-3487 SnapVault Best Practices Guide,
и TR-3466 Open Systems SnapVault Best Practices Guide.

Я помню, что обещал вам “исследование” по истории фрагментации в файловых системах, но что-то у меня пока куражу нет его дописать на нужном уровне, придется подождать. Читайте пока про SnapVault, а на следущих две недели у меня спланирована большая программа по углубленному “полосканию косточек” EMC VNX/VNXe. Не переключайте ваши браузеры, будет интересно. :)

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

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

Как и обещал чуть раньше – рассказываю про этого зверя.
Multistore – опция систем хранения NetApp, позволяющая делить физическую систему хранения на “логические партиции”.

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

Однако многое изменилось в прошлом году. Во-первых Multistore была извлечена из забвения, в котором находилась много лет, и приспособлена к многим новым инициативам NetApp, куда она удивительно органично подошла, например к Secure Multi-Tenancy. Во-вторых, появились новые и многообещающие продукты, использующие Multistore, например NetApp DataMotion for vFilers, позволяющая такие “виртуальные партиции” – виртуальные “файлеры”, созданные внутри физической системы хранения, переносить между системами хранения, даже между физически различными, и установленными в разных местах, без прерывания к ним доступа, наподобие vMotion для виртуальных машин в VMware.
И, наконец, логичным шагом стало включение Multistore в комплект ONTAP Essentials, идущий по умолчанию, и доступный целиком, без покупки дополнительных лицензий, для новых систем FAS3200/6200, что тем более делает нужным и полезным знакомство с этой интересной опцией.

Но давайте по порядку.

Multistore – это средство создавать внутри физического контроллера системы хранения множество “виртуальных”, автономных “логических” систем хранения, с автономным управлением, и своим набором данных для каждой.
Разумеется вы уже подумали про гипервизоры в стиле VMware, но – нет, все проще, используется механизм, подобный chroot или jail во FreeBSD. Это позволяет гораздо меньше “нагружать” железо, и вполне безопасно изолирует такие виртуальные файлеры друг от друга. Так, например, для самой младшей FAS2020 количество таких виртуальных файлеров ограничено 26, а для всех остальных контроллеров NetApp под версиями Data ONTAP 7.x можно создать до 65 таких ‘vfilers’ (на каждом контроллере, на HA-пару – 130), что, конечно, гораздо экономичнее, с точки зрения расхода памяти и ресурсов, так как как “сущность” Data ONTAP не множится в памяти, продолжая существовать в единственном экземпляре. Каждый vFiler занимает в системной памяти всего около 400Kb.

В отношении же безопасности изоляции данных, следует упомянуть, что, в течении нескольких лет, независимая компания информационной безопасности Matasano Security проводила security audit OS NetApp Data ONTAP, и отметила в итоговом документе:

At the conclusion of our testing, we found that the Data ONTAP operating system exceeded our expectations for security. We know of no vulnerability in Data ONTAP that would allow an attacker to use a FAS Storage System, even if they have a login to a portion of it, to compromise another subnet.

NetApp MultiStore: An Independent Security Analysis
Prepared By: Thomas Ptacek and Eric Monti, Matasano Security

Классической, изначальной областью применения Multistore, до недавних пор, была организация использования NAS-файлера в многодоменной Windows-сети, а также возможность создавать виртуальные файлеры для подразделений в компании, требующих отдельных политик администрирования и безопасности. В этом случае, вместо заведения таким подразделениям отдельных физических систем, вы могли выделить им виртуальный файлер, на котором они могли быть своим собственным виртуальным рутом, создавать на нем любые, угодные им ресурсы, с любыми нужными им политиками, все в таком своеобразном изолированном jail-е внутри физического файлера.

Такой виртуальный файлер выглядит изнутри себя как отдельный “netapp”, включая свой собственный vol0 и /etc, а попасть администратору в его контекст можно с помощью команды:

mainfiler> vfiler context vfiler1
vfiler1@mainfiler> Wed Apr 8 22:18:24 EDT [vfiler1@cmds.vfiler.console.switch:notice]: Console context was switched to a vFiler(tm) unit vfiler1.

vfiler1@mainfiler>

Далее вы можете оперировать в среде такого vfiler как в реальной системе. В настоящее время  в среде vfiler команды управления в значительной мере совпадают с тем, что доступно в “физическом” файлере.

Каковы же ограничения?

Пожалуй самым заметным следует указать отсутствие в среде такого vfiler поддержки FCP. Работают все остальные протоколы, то есть CIFS, NFS, NDMP, FTP, и так далее, но из “блочных” протоколов доступен iSCSI. То есть vfiler может работать в SAN, но в настоящее время только как iSCSI-target. Отсутствие поддержки FCP в контексте vfiler связано, прежде всего, с отсутствием поддержки NPIV в Data ONTAP, однако  она также может быть со временем добавлена. Но в настоящий момент вы не можете “виртуализовать” физический FC HBA, разделив его между виртуальными файлерами, поэтому FCP доступен только на уровне хост-системы, или vfiler0, как ее в данном случае принято называть.

Мне не удалось найти однозначных сведений по поводу текущего состояния с FCoE на Unified Target, возможно уточнят этот вопрос присутствующие и читающие меня люди из NetApp?

Что касается ethernet, то каждый vfiler оперирует своим набором IP-адресов, VLAN, VIF и таблиц маршрутизации, что позволяет оперировать с ним как с самостоятельной сущностью, с точки зрения администрирования. Например можно держать один vfiler в DMZ, а другой – во внутренней сети, оба будут находиться внутри одного физического контроллера, но данные первого будут надежно изолированы от данных второго. На физический контроллер доступно до 101 набора IPspaces, то есть логических таблиц маршрутизации.

Кроме уже упомянутой, традиционной области применения, такой как многодоменная Windows-сеть, и подразделения с индивидуальными политиками администрирования, областью применения Multistore, в особенности с новыми продуктами Secure Multi-Tenancy и DataMotion, может быть задачи Disaster Recovery или миграции данных.

Например команда vfiler migrate перенесет весь instance виртуального файлера, включая его данные и конфигурацию, IP-адреса, NETBIOS Name, hostname, на новый контроллер (требуется активированная лицензия SnapMirror).

Вы также можете регулировать загрузку физического файлера его vfiler-ами с помощью средств FlexShare и назначения приоритетов доступа к томам FlexVol. Помните, что оттого, что вы на одном физическом контроллере создали десяток виртуальных, производительность физического не увеличилась, IOPSы, выдаваемые физическим контроллером распределятся между vfiler-ами, а с помощью FlexShare вы сможете правильно сбалансировать приоритеты.

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

bitoniau: Иногда на динамику автомобиля влияют не двигатель, трансмиссия и прочие умные штуки, а сгоревшая лампочка индикации затянутого ручника
bash.org.ru

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

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

Начните со статьи в этом блоге, а также детально просмотрите описание sysstat во встроенной документации, в частности в Data ONTAP Command Reference vol1 (должна быть в комплектной документации вашей системы).

С помощью вывода sysstat вы сможете “вчерне” оценить происходящее на системе, а также понять причины какого-то странного поведения. Например, высокая загрузка дисковой подсистемы по вводу-выводу, при отсутствии входного трафика с хостов, может говорить о идущем процессе дискового “скраббинга”, высокая нагрузка на CPU при этом – о возможно идущей активной фазе процесса дедупликации данных. Маленькая величина Cache Hit – о неэффективности использования кэша системы. Короткий Cache Age – о нехватке объемов кэша, вынуждающего постоянно его опустошать для новых данных. Характер сброса Consistency Points – о характере и объемах записываемых на систему данных.

Однако это, повторюсь, только черновые, общие признаки.

К более детальным диагностическим средствам следует отнести выводы команд statit и stats. Последняя является одним из самых детальных и подробных средств, к сожалению довольно слабо документированных и с визуально очень тяжело читаемым человеком выводом, ориентированным скорее на работу собственного техсаппорта NetApp, чем анализа силами конечного юзера. Для облегчения  использования вывода stats я уже публиковал в этом блоге неплохой набор скриптов на Perl, которые осуществляют разбор и вывод данных команды stats в “человекочитаемом” виде.

Но сперва подробнее рассмотрим, что мы можем извлечь с помощью sysstats и statit.

Допустим, мы наблюдаем вот такую картину на выводе sysstat: sysstat_out1.txt (поставьте моноширинный шрифт для просмотрщика данного файла, отключите переносы строки и расширьте окно, чтобы вся длинная строка вывода влезла).

Что вас должно насторожить?

Мы видим мультипротокольную систему (FAS3140A с двумя полками дисков SATA, обслуживающая roaming profiles (от 130 до 700MB размером) примерно 3000 (до 600 одновременно работающих) пользователей под Windows XP), загруженную, главным образом, чтениями  по CIFS (до полутора тысяч операций в секунду). Обратите внимание на сравнительно невысокую загрузку CPU и сравнительно высокий уровень Cache Hit (попадания запросов не на диск, а читающихся из кэша), но при этом странное поведение CP Time/CP ty, и, что самое важное, почти полную, около 90% загрузку дисковой подсистемы. Подозрительно при этом выглядят объемы операций, как видите, в основном это чтения, и при этом не превышающие 2500-4000 килобайт в секунду. При этом на той же системе периодически проскакивающие записи могут быть и до 20 мегабайт в секунду, то есть дело явно не в слабости дисковой части. Что-то не дает дискам “разогнаться”. Ограничивает производительностьявно не процессор или память, а именно непонятная, объективно ничем не вызванная перегрузка дисковой подсистемы, ограничившая трафик на уровне 4Mb/s с всей группы дисков.

Давайте посмотрим детальнее на картину на уровне физических дисков на выводе команды statit: statit-out1.txt

Мы видим, что aggregate наш состоит из двух RAID-групп -  rg0 и rg1, в кофигурации RAID-DP 11d+2p. Диски 0c.16, 1b.17 и 0c.29, 0c.33 – диски parity. Остальные – Data.

Что тут мы видим странного. Во-первых обратите внимание на величину использования дисков 0с.25, 26 и 28, по сравнению с остальными дисками data (для дисков parity действуют другие правила, на них пока не смотрите). При средней нагрузке по дискам группы в 35%, на этих дисках загрузка почти вдвое выше, около 75%. Также высока и величина latency, она почти втрое-вчетверо выше на этих дисках, достигая 60-70 миллисекунд, против 14-17 для остальных. В нормально же работающем aggregate нагрузка должна равномерно распределяться по всем дискам aggregate.

По видимому “больное место” мы обнаружили. Проблема – в этих трех дисках, именно их аномальное поведение и перегрузка, скорее всего, и является причиной проблем. Причин возникновения такого hotspot-а может быть несколько. Например это может быть неоптимальное расширение aggregate увеличением размеров RAID-групп, о чем я как-то уже писал, при этом наиболее активные данные могут оказаться на немногих добавленных дисках, и впоследствии, при обращении к этим данным, перегрузить их, либо это признак аппаратной неисправности, как диска, так и дискового интерфейса (например большое количество ошибок на FC-интерфейсе ухудшают его показатели по latency из-за retransmission).

Итак, в соответствии с Top5, мы действительно нашли наш bottleneck в перегрузке какого-то отдельного диска (в данном случае сразу трех их), тормозящего всю подсистему.

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

UPD: Когда этот пост уже был написан, пришло письмо с ответом на мой вопрос “чем же история закончилась?” от автора и администратора рассмотренной системы. В двух словах: Да, действительно, проблема была в этих трех дисках, они подняли кейс в поддержке, диски были заменены, и все заработало так, как должно было работать.

Интересующиеся некоторыми новыми технологиями NetApp, возможно уже обратили внимание на продукт, созданный еще в прошлом году –  NetApp Data Motion for vFilers, он появился в Data ONTAP 7.3.3, и который позволяет осуществлять непрерывающую миграцию (перенос) между контроллерами так называемых vFilers, то есть “виртуальных файлеров”, “инстансов” Data ONTAP, работающих как отдельные виртуальные системы хранения, в рамках продукта Multistore.
(да когда же я вам уже про Multistore расскажу уже? Интереснейшая тема, кстати! Поставил себе в ToDo пометку: “В ближайшее время написать статью про Multistore!”, тем более теперь Multistore идет в ONTAP Essentials со всеми 3200/6200)

То есть делать примерно то же самое, что делает VMware vMotion для виртуальных машин, только для нетапповских “виртуальных файлеров”, между несущими их физическими контроллерами.

Однако в Data ONTAP 8.0.1 появилась и еще одна новая возможность – Data Moion for Volumes.

NetApp Data Motion for Volumes это новая возможность, появившаяся в версии Data ONTAP 8.0.1, и которая позволяет проводить непрервывающую миграцию на одном контроллере, для томов данных, содержащих LUN-ы, между разными его aggregates. То есть если первый был vMotion for NetApp vFilers, то второе – примерный аналог Strorage vMotion.
Первая и очевидная область применений – организация tier-инга данных, то есть, например, можно, не прерывая работы с данными, мигрировать том с LUN-ами c FC/SAS аггрегейта на аггрегейт на SATA на том же контроллере.

Обатите внимание, что это только для LUN-ов пока, то есть НЕ для CIFS/NFS. Только для FC/iSCSI/FCoE! То есть правильно было бы назвать его Data Motion for LUNs.

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

Несмотря на такие ограничения в текущей версии, возможность эта довольно интересная.

При такой миграции сохраняются все связанные с томом и LUN-ом настройки, такие как: снэпшоты и их расписания, настройки репликации для такого тома, настройки и свойства thin provisioning, дедупликации (правда на новом месте нужно провести рескан для пересоздания базы фингерпринтов, они останутся на уровне aggregate и не переедут вслед за томом, однако на уже дедуплицированные данные это не повлияет).

Подробнее на английском – в Tech OnTap за февраль этого года. Вы ведь подписаны на русскую версию? Никогда не поздно. :)

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

Так вот, обратите внимание, что из того факта, что на “зашаренном” volume вы видите LUN-ы на нем созданные как файлы, не следует, что “LUN-ы это файлы”.

Если вы, допустим, бэкапите такие LUN-ы, то бэкапить их надо ТОЛЬКО как содержимое volume, то есть от “корня”, вместе с томом, либо с qtree, если последний используется. Иначе вы потеряете при таком копировании metadata (они хранятся внутри volume), определяющие внутри NetApp LUN именно как LUN, и не сможете восстановить его на прежнее место как LUN, то есть как устройство с блочным доступом.

То есть, для бэкапа содержимого LUN, например это LUN01, лежащий на томе vol1,  недостаточно просто скопировать “файл”, лежащий по адресу //filer1/vol1/LUN01, нужно копировать целиком vol1!

Аналогична ситуация и с восстановлением. Восстанавливать надо том вместе со всеми LUN-ами на нем, а не просто отдельный “файл” LUN-а, так как, в противном случае, не будут востановлены специфические метаданные SAN-объекта.

То есть, если вы сбэкапили LUN, а затем восстановили, и не можете смонтировать его как LUN, а видите его как “просто большой файл”, то это вот тот самый случай.

Разумеется, все изложенное выше касается только “бэкапа со стороны стораджа” (например по NDMP), а не бэкапа “изнутри” OS, работающей с данным, смонтированным на нее LUN-ом, как своей файловой системой.

Еще читать: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb37566

Два параметра в свойствах FlexVol-тома NetApp, значения которых вы, возможно, не знали.

“minra” минимизирует (min) операцию упреждающего чтения (Read-Ahead, ra). Режим упреждающего чтения есть метод своеобразной оптимизации чтения. Алгоритм предсказания операций чтения старается определить, насколько высока вероятность, что следующие считываемые блоки будут располагаться последовательно, и, если да, то читает их с упреждением , read-ahead, в расчете, что данные, заранее прочитанные, понадобятся на следующей операции, а они у нас уже в памяти.

В версии DataONTAP 6.5 и ранее, алгоритм был довольно примитивен, и просто читал с упреждением блоки с диска, заполняя, подчас, память кэша чтения системы ненужными данными, например в случае равномерно-рандомного чтения. Поэтому в старых руководствах вы могли встретит рекомендации устанавливать в свойствах тома этот параметр в minra=on, то есть отключать упреждающее чтение. Это помогало сэкономить пространство кэша в случае заведомо рандомного характера рабочей нагрузки.

В версии 7, и в особенности в 7.3, алгоритм Read Ahead значительно усложнился и поумнел, и теперь предсказание упреждающего чтения работает значительно лучше и эффективнее. Поэтому для новых систем, начиная с 7.3, рекомендуется не выключать Read Ahead (НЕ ставить minra=on в свойствах тома), даже для рандомной нагрузки, предоставив работать умному алгоритму.

Второй параметр – “no_atime_upd” – отключает обновление времени последнего доступа к файлу (access time - atime), располагающемуся на файловой шаре с доступом по NFS или CIFS. В случае, если вы используете систему NetApp как NAS, и ваши приложения доступа к файлу НЕ пользуются данными last access time (это вообще используется сегодня сравнительно редко), то этот параметр лучше установить в on (выключить обновление времени последнего доступа). Этот параметр никак не влияет при использовании систем NetApp как SAN-хранилища, то есть когда том FlexVol хранит на себе LUNы.

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

Таким образом, на сегодня, оба эти параметра остаются скорее как legacy параметры, и особого эффекта их настройка не приносит.

Я уже несколько раз упоминал в этом блоге о aggregate snap reserve, пришла пора  подробнее рассказать о том, что это, зачем использутся, и нужно ли это вам.

Вы уже наверняка знаете, что такое и зачем используется Snapshot reserve на уровне тома. Это некий зарезервированный объем общего пространства соответствующего тома, используемый для того, чтобы обеспечить доступность пространства на дисках при создании снэпшотов состояния тома. Это некая условная “граница”, которую может превысить снэпшот, но не может превысить содержимое тома, пользователю тома доступно для записи место, равное объем тома минус резервация на снэпшоты. Это резервирование гарантирует доступность места для хранения данных снэпшотов, а также упрошает администрирование тома, так как пока снэпшоты не вышли за пределы отведенного резерва, свободное пространство, доступное для записи на томе, стабильно и предсказуемо.

Подробнее и с поясняющими картинками про принцип работы Snap Reserve я писал в посте ранее.

Отмечу также, что величина резерва, заданная по умолчанию в 20% от объема тома может быть изменена, и 20% это не hardcoded value, а просто такая вот эмпирически выбранная когда-то величина “по умолчанию”. Можно сделать 50, 15, 10, и даже 0%. Например 0% сегодня рекомендованная величина Snapshot Reserve в случае использования тома для хранения SAN LUN-ов (вместо Snapshot Reserve используется Fractional (или LUN Overwrite) Reserve, о смысле которого я уже также ранее писал).

С Volume Snap Reserve мы более-менее разобрались, но что же такое и зачем нужен Aggregate Snap Reservation, равный, по умолчанию, 5% от объема aggregate?

Aggregate, по сути, представляет собой свообразный мета-volume, просто такой своеобразный том, находящийся в иерархии уровнем ниже обычного FlexVol-тома. Соответственно, задача у этой резервации точно такая же – хранить блоки, использованные в снэпшоте уровня aggregate.

Что же такое “снэпшот уровня aggregate”, кто его делает и зачем он используется?

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

WAFL как “файловая система”, вследствие своей архитектуры, поразительно устойчива, 99% админов NetApp действительно никогда не сталкиваются с необходимостью “лечить” WAFL. “Уронить” WAFL в принципе возможно (“Если один человек чего сделал, то другой завсегда сломать может”(с)) но это, как показывает моя практика, довольно нетривиальная задача.

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

Также, с использованием снэпшотов уровня aggregate вы можете сделать SnapRestore для aggregate целиком, вместе со всеми томами и LUN-ами на нем, если зачем-то это вам понадобилось.

Кроме этого следует обратить внимание, что какой-то объем пространства на уровне aggregate (то есть не распределенного в volumes, а непосредственно в aggregate) используют следующие средства:

1. Deduplication  начиная с версии 7.3 хранит свою базу fingerprints непосредственно на уровне aggregate, таким образом, при использовании deduplication вам понадобится какое-то небольшое пространство на aggregate не занятое томами, обычно в зарезервированные 5% эта база помещается
2. Синхронная версия репликации SnapMirror до версии 7.2.2 записывала данные, попадающие в NVRAM, в специальный файл на root volume по пути /etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]. Начиная с 7.2.7 эти данные пишутся также на уровне aggregate. Руководство Data ONTAP Online Data Backup and Recovery Guide рекомендует, в случае использования Sync SnapMirror иметь на aggregate место в объеме 20x емкости NVRAM на системе-получателе (destination).
   (обратите внимание, что у NetApp есть два различных средства synchronous replication – SyncMirror и SnapMirror Synchronous mode)
3. Наконец, не стоит забывать, что запас незанятого места на aggregate довольно значительно снижает величину фрагментации, а правильнее “non-contiguous block factor”. Напомню, что файловая система (любая, NTFS, ext3, WAFL, почти любая современная файловая система), когда ей необходимо записать файл, сперва ищет у себя фрагмент непрерывно свободного пространства, куда и пишет содержимое этого файла. Если, как это обычно бывает при сильно заполненной файловой системе, такого места отдельным, непрерывным куском нет, то файловая система начинает дробить записываемые данные файла на более мелкие фрагменты, которые уже могут располагаться непоследовательно. В наихудшем случае, файловая система располагает свободным местом только в виде отдельных, непоследовательных блоков, разбросанных по файловой системе. Наличие запаса свободного места с точки зрения файловой системы резко улучшает эту ситуацию, и позволяет не накапливать фрагментацию.

Таким образом, как вы видите, идея держать гарантированно небольшое свободное пространство на уровне aggregate имеет определенные основания на системном уровне. Если вы уверены, что ничем из перечисленного вы не пользуетесь, а 5% зарезервированных на aggregate вам жалко, то вы можете уменьшить эту величину, аналогично ситуации с volume snap reservation, , например до 2-3%, практика показывает, что этого достаточно. Можно, хотя это и не рекомендуется, и вовсе отключить эту резервацию. Обратите также внимание, что, как и в случае с volume snap reserve, отключение reservation не отключает возможность использования snapshots, если на структуре (volume или aggregate, соответственно) есть свободное место. Это просто средство некоторого упрощения жизни и работы админа, и только.
Помните, тем не менее о том, что у NetApp за каждым default value стоит какая-то причина, и прежде чем вы не уясните эту причину, я бы не рекомендовал “твикать” не глядя, это все же не “реестр венды” ;).

Посмотреть текущее состояние резервирования и назначенное расписание создания снэпшотов на aggregate:

fas1> snap sched –A
Aggregate aggr0: 0 1 4@9,14,19 - установлено расписание создания снэпшота aggregate в 9, 14 и 19 часов, и хранение с ротацией одного дневного и 4 таких "почасовых" снэпшота.

fas1> snap sched –A aggr0 0 0 0 - создание снэпшотов aggregate aggr0 отключено.

Для изменения величины или отключения резервирования на aggregate вам нужно использовать команду:

fas1> snap reserve –A aggr0 3 – устанавливаем величину резервирования для aggr0 равную 3%