about NetApp

Теперь давайте посмотрим как на всем этом, рассмотренном в прошлом посте, располагаются пользовательские данные.
Поверх “слоя виртуализации” - 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, и добавляет за это каких-нибудь возможностей.

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