about NetApp

Предыдущие посты серии:

Первый
Второй
Третий
Четвертый

Итак, aggregate созданы, а на них созданы, в свою очередь, тома (volumes).
“Том” (Volume) есть основной элемент структуры хранения NetApp.
Вся информация, и все вышележащие структуры данных, такие как “сетевые шары” и LUN-ы располагаются внутри “тома”.
В частности именно на том действуют снэпшоты.

На каждом томе можно создать 254 снэпшота. С учетом максимального количества томов, возможных на системе, получается суммарно около 51 тысячи. Впрочем это скорее теоретическая величина, поэтому заостряться на ней не будем, что же касается снэпшотов то вам их, я полагаю, хватит в любом случае. Напомню, что решения, называющие себя “снэпшот”, у конкурентов обычно заметно ограничивают их количество в 14-30 на всю систему в целом (см. комментарии). Такое ограничение вызвано не в последнюю очередь тем, что использование snapshots у таких систем резко влияет на производительность, и, обычно, снэпшоты на них массово просто не применяются, так как весьма значительно “сажают” производительность системы в целом.

Раз мы добрались до тома и его снэпшотов, позвольте подробнее остановиться на непростой, и вызывающей множество непонимания теме “резервирования” или snapshot reserve.

Когда-то, давным давно, когда NetApp был только NAS системой, было эмпирическим путем определено количество места, которые отводятся и резервируются под снэпшоты, в 20% от общего объема тома. То есть, для простоты понимания на конкретном примере: из тома в 100MB на блоки, зафиксированные в снэпшоте, мы отводим 20MB (на основные данные остается, соответственно, 80MB).

Для правильного понимания того, как работает резервирование, стоит нарисовать вот такой рисунок:

В ней, для простоты изображения и понимания, данные, записываемые на том, прирастают снизу.

Блоки, попавшие в снэпшоты, прирастают сверху.

Граница “резерва под снэпшоты” это линия, отделяющая верхние 20% емкости, в которых прирастают (условно сверху вниз) данные снэпшотов.
При этом, граница эта “проходима” сверху вниз, но не снизу вверх. То есть, если случилось так, что снэпшотов создалось больше, чем на 20% резерва, например на 25, то будет заняты “сверху” 20, и плюс еще кусочек на 5% “сверху” от активного тома.

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

Перед этим система будет сыпать алертами о исчерпании места, например в уже рассмотренном случае, когда снэпшоты “вылезли” из пространства резерва, в сообщении будет говориться о “заполненности тома на 105%”. Проценты свыше 100 это как раз то, насколько из резерва вылез хвост объема снэпшотов.

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

Можно ли изменять величину снэпрезерва? Разумеется да.
Можно ли поставить ее в 0%? Да.
Отключит ли это возможность создавать снэпшоты на томе? Нет, просто снэпшоты сразу будут занимать место в пространстве “активной файловой системы” тома. Представьте, что граница с рисунка поднята до упора вверх, но она по прежнему проходима для снэпшота, растущего сверху вниз.
Чем это грозит? Да по сути ничем, просто вам надо будет либо не пользоваться снэпшотами (опрометчивый, но имеющий право на существование способ использования стораджа NetApp), либо внимательно контролировать заполнение тома и величину пространства, занятую снэпшотами, чтобы они случайно не исчерпали собой доступное для данных место.
Зачем вообще нужно это резервирование? Ну это просто удобно. Сисадмин системы хранения знает, что у него всегда есть специальный запас места для создания снэпшотов, что туда никто кроме них не залезет и не займет, и снэпшоты, пока это место не переполнится, всегда на томе будет где создать. То есть это просто такое средство немного облегчить жизнь и снизить количество мест, которые надо контролировать.

Традиционно решение ставить snapreserve в 0% применяется при использовании системы NetApp в качестве чистого SAN, когда на volume создается LUN, равный ему по размерам, а создание снэпшотов не используется, и не планируется.
Однако чаще для такой конфигурации, в особенности когда планируется _использовать_ снэпшоты, рекомендуется устанавливать резервирование в 100%. Тогда, даже в самом наихудшем случае, когда все блоки LUN-а изменены, то места на снэпшот хватит.

Я уже писал подробно про этот вопрос в посте про использование “Fractional Reserve”.
Там же я рассказывал про другой способ решения проблемы снэпшота для тома с LUN - автоматическое увеличение тома, опция “autogrow”, в том случае если на aggregate, где он расположен, есть свободное пространство.
Вы можете не резервировать место при создании тома, а просто в свойствах тома сказать, что, когда понадобится, он может расти, занимая под себя свободное место в aggregate.

Итак, мы создали том, и задали ему snapshot reservation ту, какую захотели, например 20, или 15% в случае планов использования данного тома под хранение файлов (NAS), 0 или 100%, или определили fractional reserve, опции autogrow и autodelete, при использовании его для размещения на нем LUN-а.

…и почти добрались до конца. Теперь давайте посмотрим, что же у нас получилось с usable.
Окончание (надеюсь) в следующий понедельник (надеюсь).

Да уже и не must, а почти что almost.

Еще несколько слов аргументации за переход к RAID-6, тем, у кого он не тормозит, не будем показыват пальцем, но: “Есть такие вендоры!” ;).
Да, согласен, RAID-10 тоже вполне может пережить отказ двух дисков, если вам повезет, что это произойдет в разных половинах “зеркала”. Но только в этом случае.

—————
RAID 5 появился в 1987 году, и был вполне адекватен решаемым задачам на протяжении следующих 15 лет непрерывного роста. Обычный размер диска в 1987 был всего 21MB, да, именно МЕГАбайта, и скорость вращения была 3600 RPM. На протяжении следующих 20 лет, диски выросли до 1TB (в 50 тысяч раз больше, но только вдвое-вчетверо в скорости вращения). Этот огромный рост привел к проблеме и продемонстрировал ущербность данного уровня RAID.

Проблема заключается во времени, которое уходит на перестроение большого по объему RAID, которое может исчисляться днями. Это может привести вас к проблеме выхода из строя второго диска на том же RAID, в то время, как процесс ребилда еще не завершился. Величина под названием Annual Failure rate (AFR) для дисков становится лучше год от года, но это не устраняет проблему продолжающегося роста времени ребилда. Другая проблема состоит в том, что в процессе ребилда нагрузка на диски существенно возрастает, что, в свою очередь, увеличивает вероятность отказа, так что процесс ребилда сам по себе может быть для дисков еще опаснее*1 (до 2.5 раз).

Допустим, AFR (Annual Failure Rate, “вероятность отказа”) равен 5%*2, и время ребилда равно 1 дню. Мы используем 9-дисковый RAID-5 (8+1). Шансы получить второй дисковый отказ за это время равен 1/365 x 5% x 8 x 2.5= 0.25%. Допустим, у нас используется 100 таких групп по 9 дисков в RAID 5 в системе (900 дисков). Я могу ожидать, что получу 45 отказавших дисков в течении года. Во время прохождения ребилда я “бросаю кости”. У меня есть 1 шанс из 400 получить за время ребилда отказ второго диска, приводящий к потере данных, и я “бросаю” эти кости 45 раз в год. В течении 5 лет срока службы это означает вероятность 225 из 400 получить катастрофический сбой с потерей данных.

Давайте рассмотрим теперь тот же сценарий, но удвоим размер дисков, и понизим AFR (Annual Failure Rate, “вероятность отказа”) с 5% до 4% (имитировав развитие рынка HDD и выход новых боле емких моделей дисков). Теперь у нас уходит два дня на ребилд, так как удвоился объем, и формула выглядит так: 2/365 x 4% x 8 x 2.5= 0.4%. Те же 100 RAID-групп, те же цифры предположений, но риск двойной ошибки вырос до 1 к 200, хотя я “бросаю кости” только 36 раз в год. На протяжении пятилетнего срока службы это означает шанс 180 из 200 получить катастрофический отказ.

Это выглядит противоречащим здравому смыслу, но тем не менее это так. Да, диски становятся надежнее, но при этом, тем не менее, риск аварии возрастает.

Примечания:
*1: http://www.snia.org/education/tutorials/2007/fall/storage/WillisWhittington_Deltas_by_Design.pdf, см. слайд 50
*2: Официально опубликованный вендорский AFR для дисков всегда ниже 1%Однако множество источников называют размер этой величины вплоть до 12%, Можно считать, что величина “консенсуса” в данном вопросе находится обычно между 3% и 5%.
————-
Найдено и переведено там:
http://blogs.netapp.com/msenviro/2009/08/the-raid-10-upsell-fudbeast.html

Далее переходим к созданию aggregate (вернее создание RAID и aggregate это чаще всего один этап).

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

В ряде особых случаев, некоторые рекомендации Best Practices говорят о необходимости создавать отдельные aggregates для сильно различных типов нагрузки, с тем чтобы одна из нагрузок совершенно не влияла на тома с другим типом нагрузки.
Однако в подавляющем количестве случаев, и в случаях, когда диски ваших систем не исчисляются сотнями, рекомендация заводить все физические диски в один aggregate, а уже потом разбивать емкость на отдельные volumes, дает наилучшие результаты.

Часто приходится сталкиваться с мнением, подкрепленным различными, чаще всего устаревшими рекомендациями, в особенности для баз данных, “делить базу, логи разных типов, и системные файлы, не считая собственно OS в отдельные RAID (да еще и разных типов)”. На сегодняшний день такие рекомендации (по крайней мере в отношении NetApp) стоит считать устаревшими. Они действительно могут дать результат. Но фактический проигрыш от следования им на малом числе дисков, значительно превосходит потенциальный выигрыш от разделения типа нагрузки. Ведь единая RAID-группа (aggregate), состоящая из, например, 10 дисков будет заведомо быстрее по IOPS, даже на смешанной нагрузке, чем пять групп по 2 диска в каждом, даже несмотря на то, что в последнем случае удастся разделить нагрузку по отдельным дискам. Это уж даже не говоря о совершенно непродуктивном расходе места на дисках, в результате построения такой схемы.

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

Рассматривая аггрегейты, давайте остановимся на нетапповской специфике. Знакомые с системами хранения от EMC и Hitachi уже знают некоторую особенность дисковой организации на таких системах. На нескольких дисках такого стораджа размещается некая “служебная область”. Там, например, хранится содержимое внутренней OS системы, туда, например, делается “слив” содержимого кэша в случае выключения, и так далее, подробности обычно не объявляются, и область эта закрыта.
Например у EMC Clariion CX4 с каждого из 5 дисков, отведенных системой под эти нужды (так называемый Vault), отнимается по 62GB (в CX3 - 33GB), то есть “минус 310 MB” на систему в целом.
Такая схема, кроме всего прочего, заставляет при создании RAID, выделять эти 5 дисков (4 в случае Hitachi модели AMS) в отдельный RAID, так как в противном случае они уменьшат размер всех остальных дисков в этом RAID на те же 62GB, ведь объем всех дисков в RAID должен быть абсолютно равный.

Нечто подобное есть и у NetApp. Он хранит настройки системы (для знакомых с UNIX-ами скажу: раздел /etc UNIX-подобной файловой системы ядра) на самих дисках системы хранения. Остальная OS Data ONTAP находится и грузится с Compact Flash-карты, так как она совсем небольшая, несколько десятков мегабайт на все.

По умолчанию этот /etc хранится на своем собственном aggregate (aggr0), состоящем из двух (в случае RAID-4) или трех (RAID-DP) дисков: диск данных, один или два диска parity. На этом aggregate создается том vol0, на котором и лежит около 200 мегабайт содержимого этого самого /etc: настройки, конфигурационные файлы, прошивки firmware для дисков, и так далее.
Такая схема позволяет, в частности, легко переносить данные между системами хранения, а также, в случае необходимости, заменять и апгрейдить контроллер, так как вся конфигурация конкретной системы, по сути, от ее контроллера отделена. В случае замены “головы”, новый контроллер загружает “конфигурациенезависимое” ядро, монтирует к нему /etc, прочитывает оттуда конфигурацию текущей системы - и готово.

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

Для системы с небольшим количеством дисков и невысокой предполагаемой загрузкой бывает жалко отдавать отдельный aggregate и целых два-три диска только под служебную директорию размером в несколько мегабайт, особенно если используются большие диски, например при дисках SATA 1TB вы теряете на первом aggregate 1 или 2 TB на диски parity, и еще один диск под служебный vol0, пусть на нем и можно хранить данные. Все равно это минус 2-3 диска целиком, из общего количества.

В этом случае можно порекомендовать создать единый aggregate, в который войдут все диски системы, и уже на нем выделить vol0 под системный раздел.
В этом случае общая производительность вашего aggregate увеличится на величину 2..3 * IOPS одного диска, ведь, как я писал выше, общая нагрузка ввода-вывода в aggregate расделяется поровну по всем входящим в него дискам.

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

Продолжение как всегда следует в следующий понедельник.

Итак, в предыдущих двух постах этой темы (часть 1, часть 2) я постарался показать, что такое usable space по сравнению с raw space, почему первое всегда меньше чем второе, и почему мы, заплатив за полновесные терабайты получаем на выходе якобы совсем не те терабайты, за которые мы заплатили.

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

Один из блоггеров NetApp, которого я постоянно читаю, Костадис Руссос, использует в своих постах, в особенности в своих спорах с EMC, термины “Real Fibre Channel” (который так любят Наши Уважаемые Конкуренты) и “Better Than Real FibreChannel” :)

Давайте посмотрим, где же NetApp является “Better Than Real FibreChannel”.

Пост планируется длинный, я разбил его на несколько частей, которые будут идти в несколько приемов, так что готовьте кофе ;)

Итак, как уменьшается пространство по пути от “raw data” к “usable data + функционал”?

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

Бородатый анекдот: “Шофер думает, что в килобайте 1000 байт, а программист - что в километре - 1024 метра”

Так вот, емкость в “двоичных байтах” получается больше, что очень нравится маркетерам компаний по производству жестких дисков: “А в попугаях я гораздо длиннее!” (с) Удав

Строго говоря уже в обед как сто лет принято решение ISO (International Standartization Organisation) для “двоичных байт” использовать специальные приставки, чтобы отличать двоичные и десятичные множители, звучат они непривычно, и немного смешно: не кило- а киби- (би - “бинарные”, двоичные единицы), “мега” - “меби”, и так далее.
Но пока есть что есть, и из диска на один “терабайт” (как называет его производитель), который на деле “тебибайт”, “исчезает” за счет этого почти сто мегабайт.

Аспект номер два - сектор 520 байт на 8 байт больше обычно используемого. Зачем это так сделано я писал тут и тут. Это уменьшает емкость диска примерно на 1/64 долю, повышая надежность хранения и позволяя использовать дедупликацию.

Далее переходим к RAID-ам. Как вы знаете уже, на системах NetApp используется RAID тип 4 (чередование с четностью, с выделенным диском четности), который имеет емкость X*N-X, где X - это емкость одного диска, а N это число дисков в RAID-группе, то есть на обеспечение отказоустойчивости занимается один диск.
Второй применяемый тип RAID, это вариант RAID-6 под названием RAID-DP, в нем на обеспечение отказоустойчивости занимается два диска (X*N-2X). Такой тип RAID рекомендуется использовать по умолчанию.

Максимальный размер RAID для дисков FC и SAS - 28 дисков. Для SATA - 16. Меньший размер RAID в случае SATA диктуется меньшей надежностью дисков, более высокой вероятностью выхода из строя и ошибок, что потребовало ограничить размер RAID. Кроме того, скорость rebuild на длинном RAID для относительно медленных дисков SATA может быть неприемлимо низкой.
При необходимости использовать большее количество дисков необходио создавать две и более группы, на каждую из которых будет потрачено по 2 диска четности (в случае RAID-DP).
Обратите внимание, что максимальный размер RAID для группы типа RAID-4 в два раза меньше, то есть 16 для SAS и FC, и 8 для SATA! Большая разрешенная длина группы RAID-DP также связана с его более высокой надежностью и отказоустойчивостью.

Следующий этап - диски hot spare. Система NetApp назначает все неиспользуемые в действующих RAID-группах диски в Hot Spare. Затем из пула hotspare-дисков вы можете их забрать, создавая RAID-ы, aggregates тома. Более того, эксплуатация системы без Hot Spare дисков вообще - настоятельно не рекомендуется. Это, в принципе, наверное возможно (например какая-нибудь тестовая инсталляция с абсолютно неценными данными, но ограниченная по дисковым ресурсам), но это должно быть осознанное решение, риск которого полностью возлагается на администратора системы. Для отключения весьма надоедливого уведомления о работе без hot spare необходимо установить одну из системных опций в настройках (курите маны, если что - я ни при чем.).
Но это, повторюсь, не рекомендуется, и является нештатным и рискованным режимом.
В нормальном состоянии необходим один hot spare на каждый контроллер кластера, причем для каждого используемого типа дисков.
Например, если у вас “двухголовая”, двухконтроллерная кластерная система, в которой используется два типа дисков, например 300GB и 450GB FC, или 300GB SAS и 750GB SATA, то вам нужно будет иметь spare каждого из типов, то есть отдельно 300 и отдельно 450, или отдельно 300 SAS, и 750 SATA.

С некоторых пор Data ONTAP предлагает иметь два hot spare на контроллер минимум.
Это связано с некими внутренними “маневрами” системы, и в принципе, как и в случае с работой без hot spare вообще, это может быть отключено в системных опциях ONTAP.
Лично вот мне, как частному лицу, кажется, что держать _четыре_ hot spare на систему (по 2 на контроллер) это уже откровенный перебор, даже для достаточно крупной системы, что уж говорить о наиболее популярных у нас “голова плюс одна или две полки”.

* Изменить установку по умолчанию в 2 spare можно установив опцию raid.min_spare_count в 1, однако добавлять диски в aggreate придется в командной строке, так как для FilerView установку в 2 spare для ONTAP выше 7.3 изменить не удается (она просто не даст вам в GUI использовать дисков больше чем “все диски головы минус два”).
> aggr add [aggrname] -d [diskname]

Тем не менее, всякий раз, когда вы меняете настройки принятые по умолчанию - подумайте дважды. Или как было написано в “шапке” конфигурационного файла одной из линуксных программ: “Уберите свои руки от наших установок по умолчанию!”

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

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

Что же такое дедупликация, или, как она называлась раньше у NetApp, ASIS - Advanced Single Instance Store?

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

Однако есть другие варианты, наиболее просто демонстрируемый и широко распространенный сегодня - содержимое виртуальных машин. Если у вас есть пять виртуальных машин на базе Windows, то у вас есть, скорее всего, пять полностью идентичных инсталляций Windows, минимум на 2-3 гигабайта каждая, отличающихся на момент их создания, грубо говоря, только “именем компьютера” и IP-адресом, лежащих отдельно друг от друга на дисках, и занимающих свои 2-3 гигабайта.
Однако, так как это содержимое хранится внутри файла “виртуальных дисков”, то обычными методами мы никак не сможем устранить это дублирование. Ведь файлы этих виртуальных дисков все же не идентичны (на какие-то единицы процентов).
Аналогичный пример - базы данных. Если у нас для записи базы данных для полутора тысяч сотрудников указано “не женат/не замужем”, равно как и наоборот, или, например, в поле “город” указано “Москва”, а предусмотренное архитектурой базы BLOB-поле для хранения фотографии у 90% пустое, то это также будет дублированием.

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

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

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

“Хэш-функция” это некая формула, по которой можно получить более или менее уникальный “фингерпринт”, “цифровой отпечаток пальца”, некое число, уникальное для данного сочетания байт. Сравнивать такие числа гораздо проще, чем содержимое файлов, от которых они взяты.
Простейший вариант хэш-функции, это так называемая “контрольная сумма”. У нас есть набор чисел-байт, давайте просуммируем их, и на выходе получим некое число, зависящее от значения тех, кого мы просуммировали. Проблема использования простейшей контрольной суммы очевидна.
Сумма 5+3+2 дает 10. Но и сумма 4+4+2 дает тоже 10.
Это называется “хэш-коллизия”, ситуация, когда разные по содержимому блоки дают идентичный результат хэш-функции. Чем это чревато - нетрудно сообразить. Основываясь только на результате хэша мы можем ошибочно удалить вовсе не идентичные по содержимому данные.

Решение в общем-то очевидно. На самом деле никто не пользуется примитивной контрольной суммой, я ее привел просто в качестве примера, иллюстрирующего проблему.
Для вычисления хэш-функции используются различные математические алгоритмы, более устойчивые к хэш-коллизии, наиболее известны, например, CRC32 или MD5.
Более устойчивые - да, но не абсолютно.
Устроит ли вас результат, что “ваши данные скорее всего, с высокой степенью вероятности, не будут ошибочно удалены”? По видимому - нет.

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

Именно это является причиной того, что массивно-дедуплицирующие системы, например такие, как система типа CAS (Content-addressable Storage) EMC Centera, очень, ОЧЕНЬ медленные на запись.

NetApp, представив в 2007 году свое решение той задачи, предсказуемо пошел своим путем.
Как я уже упоминал, системы NetApp хранят результат CRC, это сравнительно простой в вычислении и “недорогой”, но недостаточно устойчивый к коллизиям алгоритм вычисления, для каждого 512-байтного блока. Этот CRC достается нам, по сути, бесплатно, он в принципе уже есть на дисках, хотим мы этого, или нет, пользуемся им, или нет.
Но использовать только его для определения дубликатов нельзя.

Файловая структура WAFL, лежащая “в основе” всех систем хранения NetApp использует блок данных размером 4KB, то есть 8 таких секторов.
CRC от этих 8 секторов дают нам некий более или менее уникальный fingerprint такого блока.
Эти фингерпринты сводятся в массив внутренней “базы”, по которой производится поиск идентичных фингерпринтов. Как вычисление несложного хэша, так и поиск по значениям такого хэша, это, в принципе, не слишком сложная и ресурсоемкая задача, тем более, что, как я написал выше, значительная часть задачи уже и так решена, так как CRC у нас уже есть для всех секторов “бай дизайн”, изначально, по умолчанию.
Идентичные фингерпринты являются основанием предполагать идентичность соответствующих им блоков.
Обратите внимание, не “означают идентичность”, для этого алгоритм слишком прост.

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

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

Однако “чистый offline” процесса дедупликации дает нам пренебрежимо малое влияние процесса на производительность системы. Конечно многое зависит от мощности системы, характера данных, и так далее, но чаще всего пользователи сообщают о влиянии на производительность от включенной дедупликации в 0% для чтения, и в районе 5-7% при записи, то есть, во многих случаях, пренебрежимо малых величинах.
В результате, системы NetApp могут использовать дедупликацию на ролях так называемых Primary storages, то есть основных, “боевых” системах хранения, а не только на хранилищах бэкапов, DR-реплик и резервных, ненагруженных системах.
Хотя применение дедупликации на primary storages и требует соблюдения рада оговорок, оно, как показывает практика прошедших пары лет, вполне работоспособно и широко применяется сегодня. И уж точно дедупликация пригодна для разнообразных secondary storages, таких как D2D Backup, реплики данных и резервные системы.

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

Q: Насколько эффективна дедупликация для хранимых данных?
А: NetApp сделал специальный эмпирический калькулятор, с помошью которого можно приблизительно оценить результат для разных типов данных.
http://www.dedupecalc.com/

Q: А как бы не приблизительные и эмпирические цифры узнать, а на моих конкретных данных?
A: У NetApp есть небольшая программка, которую можно запустить на том данных, она просчитает по нему fingerprint и сообщит ожидаемую эффективность дедупликации. Взять ее можно у партнера NetApp, так как она под определенными ограничениями, не просите ее у меня.
Партнеру скажите, что вам нужна программка SSET под Windows или Linux, он ее может скачать с партнерского раздела.

Q: Я запустил дедупликацию (или SSET) по тому данных, на котором у меня лежит сотня full backup моих данных, и я ожидал получить высокую степень эффективности на таких данных, ведь по сути это полностью одинаковые данные за небольшими изменениями, но получил результат заметно менее ожидаемого, почему так?
A: Дело в том, что для дедупликации важна абсолютная идентичность данных в пределах 4KB-блока. Если идентичные данные имеют по какой-то причине смещение между сравниваемыми блоками, хоть на байт (такое часто случается в форматах файлов резервного копирования), они уже будут считаться неидентичными для алгоритма дедупликации FAS, который не умеет обрабатывать смещение данных в блоках. Эта проблема решена в алгоритме дедупликации для систем VTL, лучше подходящих, и специально заточенных под бэкапы.
По этой причине, кстати, дедупликация FAS так эффективна для виртуальных дисков виртуальных машин, обычно виртуальные диски всегда идентично выровнены между собой, и границы блоков для них совпадают.

Q: Как можно получить лицензию для имеющейся системы?
A: Свяжитесь с ее продавцом, он закажет для вашей системы лицензию. Она бесплатна, но она нужна. Как правило для всех новых систем она поставляется по умолчанию, как iSCSI, например.

Q: Есть ли какие-то ограничения по использованию?
A1: Конечно есть :) Для полного понимания рекмендуется прочесть соответствующий Best Practices на сайте NetApp, а из FAQ-овых вопросов - обязательно посмотрите, какой лимит определен для вашей системы хранения. Он зависит от версии используемой Data ONTAP, и на момент написания этого текста, для 7.3.1 составляет 1TB для FAS2020 (самой младшей), 2TB для 2050 и 3020, 3TB для 3050, 4TB для 3040 и 3140, выше (3070, 3160, 6000) размер тома с включенной дедупликацией может быть равен максимальному размеру тома на системе хранения - 16TB. Это ограничение вызвано нежеланием перегружать возможным процессом не слишком большие объемы памяти и процессоров для этих систем, что могло бы вызвать заметное снижение рабочей производительности системы.
Если вы создали том больше, чем разрешено для данной OS и данного “железа”, то дедупликация не запустится. С другой стороны и ничего плохого тоже не произойдет :).
А2: Обратите также внимание, что дедупликация производится только для активной файловой системы. Если много блоков данных “заперто” в снэпшотах, то степень достигнутой дедупликации будет ниже, так как блоки данных в снэпшотах не обрабатываются. Возможно со временем эту проблему решат, но пока перед началом дедупликации рекомендуется удалять снэпшоты, провести дедупликацию, после чего снэпшоты можно снова брать и использовать.

Q: Велична в 2TB на том данных, подлежащих дедупликации, это объем записываемых в него данных?
A: Нет, это именно размер тома. Если у вас на системе ограничение 2TB на том с дедупликацией, и при этом вы пишете на него данные, которые могут быть дедуплицированы вдвое, то после записи 2TB и первого прохода процесса дедупликации, у вас освободится 1TB, который вы, в свою очередь, сможете записать после окончания этого процесса. Далее по этому записанному 1TB также пройдет дедупликация, и после ее окончания вы снова получите свободное место. Но первоначально объем записи равен размеру тома, не забывайте, что это именно оффлайновая дедупликация, даже если вы заливаете 2TB нулей, вы получите эффект только после его обработки.
Однако, если вы включили дедупликацию на томе большего размера, на котором есть всего 2TB и менее данных, то дедупликация просто не включится. Важен именно размер тома.

Q: Могу я вернуть “как было” если у меня что-то пойдет “не так”?
A: Конечно, можно как включить, так и выключить дедупликацию в любой момент, а также вернуть назад “дупликацию”, если почему-то что-то не устроит.

Где еще почитать поподробнее по-русски о технических аспектах:
RUS TR-3505 Deduplication for FAS and V-series Best Practices.pdf

–
UPD:
О том, как дедупликация влияет на производительность работы систем хранения NetApp можно прочитать здесь:
Дедупликация и производительность работы

–
UPD2: Кстати, знаете ли вы, что NetApp гарантирует экономию по меньшей мере 50% объема хранения в случае использования дедупликации для данных виртуальных сред (VMware ESX/vSphere, MS Hyper-V/Hyper-V R2, Citrix Xen)?
http://www.netapp-vi.eu/ru/

Без технологии защиты, действующей “от двери и до двери”, повреждение данных может пройти незамеченным, и тогда процесс восстановления окажется длительным, трудным и дорогостоящим, если и вообще возможным. Без технологии проверки целостности данных на всем протяжении пути данных, такое необнаруженное повреждение может вести к неожиданным и трудноотлавливаемым проблемам.Недавняя статья в PC Magazine (опуликована 25 августа 2008 года) сообщает о произошедшем в реальной жизни инциденте:

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

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

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

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

Недавнее исследование¹, проведенное в Университете Висконсина, Университете Торонто и компании NetApp было сосредоточено на “тихих ошибках” жестких дисков. Исследование проводилось в течении 41 месяца, и анализировались ошибки контрольных сумм 1,53 миллионов жестких дисков.

При исследовании использовались данные блоков на уровне файловой системы, чтобы обнаружить ранее необнаруживаемые ошибки контрольны сумм. В течении 41 месяца “тихие ошибки” были зарегистрированы на 0.86% из 358000 дисках SATA и 0.065% из 1.17 миллионов дисков Fibre Channel. Хотя эти величины и невысоки, но они представляют собой необнаруживаемые, и полностью “тихие ошибки”, которые могут привести к потере или искажению данных, и, в результате, значительному простою.

–
¹
L. Bairavasundaram, G. Goodson, B. Schroeder, A. Arpaci-Dusseau, R. Arpaci-Dusseau, “An Analysis of Data Corruption in the Storage Stack “, FAST08

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

Еще в 2001 году Oracle выступил с инициативой HARD- Hardware Assisted Resilient Data - программой мер, обеспечивающих сквозной контроль целостности информации от диска до приложения.
Постепенно к этой программе присоединяются новые участники, обеспечивающие соответствующий функционал в своих продуктах. С 2003 года существует стандарт (Protection Information) подготовленный группой ANSI T10, с 2007 года в рамках инициативы DII (Data Integrity Initiative) сотрудничают Oracle, Emulex, Seagate и LSI, организована координирующая группа SNIA Data Integrity Working Group. C 2008 соответсвующие средства и поддержка, по инициативе Oracle, внесены в ядро Linux, начиная от 2.6.27.

Возможно интересующиеся темой уже знают, что в дисках NetApp используется специальный размер сектора - 520 байт, вместо стандартных 512. Именно эти 8 байт на сектор и используются для хранения дополнительной информации для защиты и обнаружения искажения информации на самом нижнем, ниже RAID уровне.

Вот как определяет этот механизм группа ANSI T10:

Protection Informаtion Standart (PI) это расширение спецификации SCSI Block Command, утвержденного техническим комитетом T10. Спецификация PI относится к коммуникации между контроллером SCSI и устройством хранения. Стандартным образом данные размещаются в 512-байтных блоках. Стандарт DIF определяет дополнительные 8 байт, увеличивающие сектор до 520 байт. Дополнительные байты используются для хранения тегов, которые используются для проверки содержимого 512 байт данных в секторе.

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

В настоящий момент на сайте Oracle в списке поддержавших и проверенных тестами Oracle EMC (Symmetrix), NetApp (все модели), Hitachi Data Systems (USP), а также “братья” последней, такие как HP XP и Sun StorEdge 99xx, и малоизвестные у нас системы NEC и Fujitsu.

Как видно из списка, среди модульных (не-”highend”) систем пока эта технология реализована (с 2004 года) только у NetApp, и у них единственных проходит полный набор тестов HARD, хотя я слышал, что EMC CLARiiON также использует “нестандартный” (на самом деле как раз стандартный, в соответствии с новым стандартом ANSI T10) размер сектора, с той же целью.
Соответствующее ПО под названием SnapValidator обеспечивает работу контрольных алгоритмов Oracle внутри системы хранения, и гарантирует полную целостность данных Oracle “от двери до двери”, от блока данных в памяти сервера, до сектора данных на “блине” жесткого диска.

SnapValidator на сайте NetApp

T10 Committee: End-to-End Data Protection Justification, July 1, 2003.

Теперь давайте посмотрим как на всем этом, рассмотренном в прошлом посте, располагаются пользовательские данные.
Поверх “слоя виртуализации” - Aggregate - включающего в себя, как правило, все диски системы, и позволяющего нам распараллеливать ввод-вывод на все имеющиеся “физические шпиндели”, находятся собственно элементы доступные пользователю, “тома” типа FlexVol или Flexible Volumes.
Непосредственно на этих томах, которые, еще раз напомню, физически “тонким слоем размазаны” по всем входящим в aggregate дискам системы, уже можно хранить файлы для NAS-систем, или создавать LUN-ы для SAN.

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

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

Для нас же важно то, что же нам дает использование поверх raw data этой файловой системы? Будем уж так ее по традиции называть, хотя следует помнить, что это если и файловая система, то в чем-то единственная в своем роде.

Прежде всего, это возможность создавать и хранить снэпшоты, самая, пожалуй, известная особенность NetApp./p pСнэпшоты, кстати сказать придуманные и впервые реализованные в индустрии систем хранения именно NetApp, работают следующим образом:

Идея снэпшотов плодотворно питает множество “фич” систем хранения NetApp. Многие возможности, такие как SnapMirror (репликация) или FlexClone (виртуальное клонирование), прямо или косвенно выросли из этого свойства WAFL.

Как я уже писал ранее, особенностью реализации снэпшота в NetApp является его “некопированность”. При создании NetApp’s Snapshot ™ данные, уже попавшие на диски, не копируются, а только сохраняется дополнительная таблица inodes. Так как WAFL устроена таким образом, что данные на нее не перезаписываются, а всегда только дозаписываются, пока блок хоть где-то использован, это гарантирует нам то, что данные в снэпшоте при таком подходе, останутся неизменными.

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

Второй особенностью следует назвать необычный тип RAID, RAID-4 (”ONTAP RAID”), и необычный способ работы с ним. Почему я рассматриваю RAID на уровне файловой системы? Дело в том, что WAFL, по сути, “спускается” в своей работе на уровень RAID- и Volume-manager.
Этот вопрос уже рассматривался в упомянутой ранее статье Костадиса Руссоса. WAFL не имеет ряда принципиальных для других файловых систем средств, например по работе с файловыми и директорными структурами, поиска и извлечения файлов, зато она оперирует на “низком” уровне RAID. То есть можно себе представить, что, по сравнению с какой-нибудь NTFS или ext3, WAFL пропорционально смещена “вниз” по этой “иерархии”. В ней меньше “высокоуровневых” средств, которые отданы “на откуп” сетевым файловым системам, таким как NFS или CIFS, или средствам блочной работы с LUN-ами, зато она, в большем объеме, чем традиционные файловые системы, работает с уровнем RAID и Volumes, в которые традиционные файловые системы не вмешиваются.

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

Обычно производители систем хранения предлагают выбор между двумя-тремя типами RAID: RAID-10 (или RAID-0+1), и RAID-5 (а сейчас к ним добавился набирающий популярность RAID-6). Ранее я писал подробную статью о RAID, и разнице между ними, интересующимся предлагаю сходить туда.
Эти типы RAID, применяемые на подавляющем количестве систем хранения, выбираются для конкретной задачи и используются следующим образом: если нужно хорошее быстродействие на запись, то все рекомендации говорят о использовании RAID-10. Его преимущества - быстрота работы. Его недостаток - мы “дарим” системе за это половину всей емкости дисков, Usable Space равно 50% от Raw. Довольно бандитские условия. ;)

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

RAID-6 применяется либо при повышенных требованиях к надежности, либо при использовании менее надежных дисков, таких как SATA. При его использовании еще сильнее снижается скорость записи (примерно на 15-20% от скорости RAID-5), так как увеличивается объем вычислений для второго диска “четности”

Против всего этого зоопарка NetApp выставляет всего два варианта, а именно: RAID-4 и RAID-DP (вариант RAID-6). Почему?
Очень просто. RAID-4 или RAID-DP, в их реализации у NetApp, практически не проигрывают по быстродействию RAID-10, но при этом столь же экономичны к usable space как RAID-5/6.
А раз так, то зачем другие типы RAID, если те, что есть, полностью удовлетворяют по всем нужным параметрам?

Вот почему NetApp не предлагает “привычные” типы RAID. Их многообразие у традиционных систем хранения просто маскирует принципиальную ущербность “классических” типов RAID, среди которых пользователю предлагается выбрать компромисс, либо пожертвовав usable-емкостью в пользу быстродействия (RAID-10), либо быстродействием в пользу емкости (RAID-5), либо и тем и другим в пользу надежности (RAID-6).

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

В ближайшие несколько постов я бы хотел поговорить о некоторых аспектах usable space на системах хранения NetApp. Usable Space на NetApp, а также методы его образования из raw, это также источник бесчисленных спекуляций наших уважаемых конкурентов (в дальнейшем "Н.У.К." ;).
Я отдельно остановлюсь на "говнилках" на эту тему в отдельном посте, а пока давайте разберем фундаментальные основы того, как из Raw Space образуется Usable Space, чтобы подойти к разбору FUD уже теоретически подкованными.

Но начнем издалека.

Итак, из чего складывается пространство usable space?
Один из документов NetApp, на который я давал ссылку раньше, так и называется:
Trading Capacity for Data Protection – A Guide to Capacity Overhead on a StoreVault Storage System
Мы платим за надежность хранения raw-байтами, и получаем, в итоге, меньшее по размерам пространство, но с разнообразными "фичами". Это естественный процесс.

Простейший случай обмена "байтов на надежность" это RAID. Мы платим пространством одного диска (в случае RAID-5), двух (RAID-6), или половиной пространства (RAID-10 AKA RAID 0+1) за надежность и быстродействие.
Поверх RAID мы можем создать журналируемую файловую систему, и получаем "фичу" хранения и обработки "файлов", то есть огранизованных структур данных, со всем им присущим, и, вдобавок, защищаем целостность этих структур. Но, разумеется, партиции, загрузочные области, таблицы размещения файлов, ACL, структуры директориев, и прочее, все это также вычтется в свою очередь из пространства, дав нам взамен вышеописанные возможности, которых не было на простом и тупом raw-диске.
И так далее, и так далее.

Мы, несомненно теряем на этих процессах мегабайты за мегабайтами, но получаем взамен все новые и новые возможности.
Смешно возражать, что, мол, если бы вы не пользовались на вашей "венде" NTFS-ом, а работали бы прямо в адресации ATA, вы бы могли использовать больше места на диске, которые с ним заняты "непонятно чем".
Уже всем сегодня понятно - "чем".

Из чего же складывается, в свою очередь, usable space на NetApp?

Как вы уже знаете (по крайней мере те, кто давно читает этот блог;), NetApp, как "система хранения данных", довольно "высокоуровнева" по природе, если воспользоваться терминами из области языков программирования. Также как, например, какой-нибудь C# или Java позволяет пишущему полностью абстрагироваться в программе от, например, физической структуры регистров процессора и управления памятью, и заняться более продуктивными вещами, чем вычисления адресов, так и в случае использования пространства хранения на NetApp администратор системы хранения может абстрагироваться от "дисков" и "raw bytes".

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

Он также как и "обычные системы хранения" (тм) использует нижний уровень виртуализации, в виде RAID (RAID это, с точки зрения железа ведь тоже некий "виртуальный девайс"), но начиная с версии своей OS Data ONTAP версии 7 сделан еще один шаг в направлении "высокоуровневой" виртуализации - Aggregates и FlexVol-ы.

Aggregates это "слой дисковой виртуализации", структура (одна или несколько), в которую включены множество имеющихся у системы дисков, своеобразный disk pool, среди которых и распределяется нагрузка ввода-вывода.

Я уже писал раньше о важности такого параметра, как IOPS - Input-Output operations Per Second.
Для отдельного диска величина IOPS сравнительно невелика (в пределах двух, максимум трех сотен для SAS или FC, значительно меньше для SATA). Для того, чтобы увеличить производительность в IOPS, создатели дисковых систем хранения объединяют диски, например с помощью создания RAID-групп. Так, например, RAID-10 ("зеркало" с "чередованием") из 10 дисков будет иметь примерно вдесятеро большую производительность по IOPS, чем отдельный входящий в него диск. Это стало возможным за счет того, что, хотя для внешнего потребителя RAID это "один большой диск", внутри же он состоит из множества меньших, на каждый из которых мы можем писать свою порцию более-менее в параллельном режиме.

Однако бесконечно удлинять RAID тоже нельзя, так как снижается надежность и ухудшаются некоторые другие параметры. Кроме того далеко не всегда для данных, требующих высокой скорости, нужно так много места. А объединив 10 дисков по 300GB в RAID-10 мы получим "диск" размером полтора терабайта (300*10/2) под один только наш "скоростной файл". И так для каждой задачи.
Как правило производители "обычных систем хранения"(тм) выходят из положения путем возможности "конкатенации" (сложения A+B+C+D…) сравнительно небольших RAID-групп, и создании на получившемся пространстве так называемых LUN - логических устройств - "дисков".
Как видите, тут тоже своя "виртуализация" имеется.

Большим прорывом в свое время стала разработка уже покойной компанией DEC дисковых систем хранения, в которых появилась возможность объединить все "адресное пространство" жестких дисков, имеющихся в системе, в единый "пул байт", и уже поверх этого пула образовывать "виртуальные RAID" и разделы данных. Наследницы этих систем по сей день производятся компаний HP под названием EVA - Enterprise Virtual Array, и занимают до сих пор довольно значительную долю рынка, хотя нельзя закрывать глаза на тот факт, что системы эти постепенно (и все заметнее) морально устаревают, несмотря даже на столь прорывную и революционную идею в их основе.

Преимуществом объединения всех дисков в "общий пул" является возможность распределить входную нагрузку на все эти диски, работающие параллельно, нарезав на них нужное количество LUN нужных нам размеров, которые, свою очередь, также окажутся размазанными на все наши диски. При этом мы не платим за это "длинным RAID" и всеми его минусами, в виде, например, длительного ребилда и пониженной надежности. То есть, если мы имеем систему с 30 дисками, то, если мы сведем все эти диски в один aggregate, нарежем на нем нужное количество FlexVol, и насоздаем LUN (или будем использовать FlexVol под хранение файлов), то производительность каждого такого FlexVol, и LUN на нем, будет равна: 30*300 IOPS = ~ 9000 IOPS.
Все цифры, разумеется, условные и грубоприближенные, но с сохранением порядка.

Итак, начиная с Data ONTAP 7, структура хранения выглядит примерно так:

То есть - физические диски, над ними Aggregate, над ними RAID-ы в WAFL, на ней FlexVol-ы, на которых уже, в свою очередь, располагаются LUN-ы или "сетевые папки" NAS.
Каждый из этих уровней немножко отнимает от raw space, и добавляет за это каких-нибудь возможностей.

Продолжение в следующем посте.

Костадис Руссос (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, не идя на компромиссы в отношении скорости работы.

Не скрою, среди отдельных штук в NetApp есть вещи, способные поставить в тупик.
По моим наблюдениям, изрядным камнем преткновения для пользователей, вот уже несколько лет, является так называемый fractional reserve, как и вообще вся “кухня” распределения пространства под LUN на системах хранения NetApp.

Что же такое этот “загадочный” fractional reserve, и как его правильно использовать?

Думаю, что изрядная доля проблем понимания вызвана, в первую очередь, неудачным термином.
Fractional - “дробный”. но что там дробится, и зачем - остается непонятным.
Я заметил, что в некоторых продуктах, выпущенных NetApp в последнее время появилась более удобоваримая замена для этой “фичи”: Overwrite reserved space - “резерв под перезапись”.

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

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

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

Однако очевидны и недостатки. Такой метод довольно расточительно расходует место на дисках.

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

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

Но что случится, если на томе, где мы этот LUN создали, не окажется места для всех перезаписываемых блоков? Очевидно, что ничего хорошего не произойдет, так как в какой-то момент очередного свободного блока процессу записи не достанется, и запись не произойдет с сообщением “No available space at SCSI device”.
В жизни при этом Data ONTAP переводит LUN в offline, чтобы защитить имеющиеся данные от возможных повреждений и сохранить их в целостности.

Для того, чтобы избежать этой неприятности и придумано резервирование типа fractional reserve или, что понятнее звучит, overwrite reserved space.

Это место, резервируемое на том (flexvol), оставленное на нем тот случай, когда содержащийся на томе LUN будет активно переписываться, и понадобятся дополнительные блоки, для того, чтобы разместить эти изменения, в том случае, если прежние блоки по той или иной причине “заперты” и не высвобождаются. Например в случае взятия снэпшота.

Размер этого резервирования можно задать от 0% (резервирования нет, запись возможна только при фактическом наличии места на томе, ничем больше не занятого), до 100% (зарезервировано место, равное размеру размещенного LUN, для остальных задач системы хранения это место недоступно).

Последний вариант дает безопасные гарантии того, что сколько бы вы не написали в LUN, у вас сохранится достаточно места для перезаписи, и вы не столкнетесь с проблемой “No available space left on SCSI device”.
Однако это означает увеличение вдвое занимаемого места для LUN.

Однако NetApp не был бы нетаппом, если бы не предлагал варианты.
Вариантов, на самом деле, существует несколько.

Во первых, возможно не использовать именно 100% резервирования. Например, вы знаете, что ваш LUN сравнительно мало заполнен, или количество записей в него невелико. В таком случае, вы можете выбрать меньший размер резервирования. Например, вы знаете, что в вашем 500GB LUN, расположенном на 1TB томе, в настоящий момент занято не более 200GB. Очевидно, что перезаписи скорее всего будут выполняться в пределах этих 200GB, а резкий рост объема записи в настоящее время маловероятен. Тогда вы можете выбрать резервирование 20%, и сэкномить пространство на томе для других задач.
Однако нужно будет настроить мониторинг объемов свободного места на томе, и внимательно следить за его состоянием, чтобы избежать проблем переполнения.
Помните также, что резерв выделяется на том целиком, а не на LUN. Это значит, что если у вас на томе лежат два 200GB LUN, и резерв выставлен в 30%, то это значит, что один из этих LUNов может измениться (вырасти), при необходимости на 60% (30% своих и 30% соседа).

Во вторых, можно включить опцию snapshot auto-delete, при этом, при нехватке места под данные система попытается удалить старые снэпшоты, и освободить место на томе.
Обратите внимание, что триггер auto-delete может не успеть сработать при резком росте объемов, просто не успеет закончить удаление, оно не мгновенно. Также следует помнить, что если вы пользуетесь client-side ПО управления снэпшотами, например каким-то из SnapManager, то ему может очень не понравиться, что снэпшоты на томе удаляются без его ведома.

В третьих, можно включить опцию volume auto-grow, и тут уже сам том будет иметь возможность увеличиваться с заданным шагом и до заданного предела в объемах, для того, чтобы вместить необходимые данные.

Итак, мы видимо, что NetApp предлагает нам несколько вариантов действий. Зарезервировать 100%, на наихудший вариант, и “спать спокойно” - “ленивый” вариант. Внимательно подумать, проанализировать, и зарезервировать столько, сколько в реальности потребуется - “умный” вариант. И, наконец, подойти с другой стороны, и воспользоваться возможностями автоматического ресайза (или автоосвобождения) тома. По моим наблюдениям, этот вариант сейчас встречается чаще всего, так как позволяет занимать место на дисках только по мере реальной необходимости в нем - “экономный” вариант.

Чтобы не раздувать пост я перенесу практическую “лабу” во второй пост этой темы.