about NetApp

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAN и WAFL

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

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

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

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

LUN и WAFL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из камней, лежащих в основании системы хранения NetApp, наряду с собственной версией UNIX-подобной OS, является внутренняя файловая система, собственная разработка компани, под названием WAFL - Write Anywhere File Layout - “Файловая система с записью повсюду” :)

Откуда такое название, и что она дает системам хранения Network Appliance?

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

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

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

К особенностям “программно-аппаратной” реализации файловой системы следует также отнести и “аппаратный журнал” - NVRAM. В отличие от журналируемых файловых систем “обычного типа”, в которых журнал вместе с данными хранится на том же самом диске (обычно в особой области данных), журнал в WAFL размещен в специальном аппаратном устройстве, которым оснащены все системы хранения NetApp - устройстве Non-Volatile RAM, модуле оперативной памяти с батарейным питанием.

Несмотря на то, что блок NVRAM внутри NetApp выглядит очень похоже на Write-back cache у большинства вендоров систем хранения и серверов (плата с модулями DRAM и батареей резервного питания), функция его полностью иная.

Ну и, наконец, важной особенностью и отличием от широкоизвестных журналируемых файловых систем является параллельная поддержка двух схем разграничения доступа, т.н. “UNIX-style” и ACL(Access Control List) или “Windows-style”. Это связано с необходимостью поддержки на одном устройстве как файлов UNIX-”мира”, так и Windows-систем.
Таким образом, работая как NAS, устройства NetApp могут обслуживать как UNIX- так и Windows-машины, обращающиеся к одним и тем же файлам. Взаимное соответствие пользователей двух “миров” настраивается через таблицы взаимных соответствий пользователей, при этом система хранения понимает, что пользователь jmith подключающийся по NFS и DOMAIN\JohnSmith (или johnsmith@domain.local) это один и тот же человек, и соответствующим образом разрешает ему доступ к данным вне зависимости от того, как он в систему хранения попадает, через NFS или CIFS.

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

Подробнее (и по-английски) об устройстве файловой системы WAFL можно подсмотреть тут:
File System Design for an NFS File Server Appliance
Dave Hitz, James Lau, & Michael Malcolm | Network Appliance | TR 3002 http://www.netapp.com/library/tr/3002.pdf