about NetApp

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

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

Десять лет жили себе, не тужили без него, и вот на тебе, счастье на нашу голову. Зачем нам этот RAID новый, или старых не хватает?

Получается что не хватает, и давайте смотреть чего именно.

Во-первых, почему о RAID-6, или “RAID c двойной четностью” заговорили именно сейчас?
Причина - в резком, и продолжающемся росте емкости единичного жесткого диска.
Количество байт на устройство становится все больше, а вероятность сбоя чтения, исчисляемая в случаях на количество прочитанных-записанных байт, остается практически неизменной. Я сейчас говорю не столько о надежности самого диска вида “сломался”, сколько о надежности математики чтения с поверхности дисков.

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

То есть если раньше один случай вероятного сбоя вида “неверно прочлось и не исправилось математикой контроллера, oops…” был распределен на объем прочитанных байт, расположенных, например, на десятке дисков, то теперь, когда емкость одного диска увеличилась, количество дисков, несущих этот же объем байт, резко сократилось. ?? теперь вероятность сбоя дисковой группы резко выросла. Ведь теперь сбой возможен на гораздо меньшем количестве дисков. Допустим раньше у нас был массив в 4TB из 30 дисков 144GB. Создав на нем 6 групп RAID-5 4+1 мы получаем, что мы готовы перенести, без потери данных, до 6 сбоев диска, по одному в каждой RAID-группе.
Но времена меняются, и теперь 4TB это всего 5 дисков вида RAID-5 4+1. А вероятность в, условно допустим, 6 сбоев на такой объем осталась прежней.

Это значит, что на больших массивах, RAID-5, защищающий от единичного сбоя, больше не защищает ни от чего.
Это значит, что в случае дискового сбоя, на время ребилда RAID, а это время на дисках 146GB под нагрузкой занимает до суток, а на дисках большего размера, соответственно, больше, сообщают о величинах до 80-100 часов.
Готовы ли вы примерно на четверо суток оказаться без RAID для ваших данных вообще?
“Без RAID” (RAID-0, другими словами) потому что на время ребилда любой сбой чтения-записи, на любом диске, приведет к потере данных теперь уже гарантировано.

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

Показательная иллюстрация была найдена в документации NetApp.

А это - данные HDS (чтобы вы не думали, что это все пропаганда в пользу одного вендора).

Отчасти задача, казалось бы, решается с помощью RAID-10 (RAID 0+1). При благоприятном стечении обстоятельств мы можем пережить отказ в половине дисков, однако, если эти диски из разных “половин” зеркала. Однако, как заметил еще Мерфи, обстоятельства склонны случаться в наихудшем из возможных вариантов.

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

Ну хорошо, скажете вы. Отчего мы тогда все не применяем RAID-6 повсеместно?

Увы, один, но значительный минус присутствует. Будучи сравнимой в показателях производительности при Random Read, Sequential Read и Sequential Write, RAID-группа с типом 6 как правило сильно проигрывает (практически на треть!) на Random Write, что практически лишает RAID-6 шансов на использование в задачах, критичных к быстродействию по тому параметру, например OLTP-базы данных, и подобных им. Более того, практически, применения RAID-6 в его классическом виде, возможно только на весьма ограниченном пространстве задач, таких, как, например бэкапы, или DSS-базы, то есть задачи без Random Write. По крайней мере Best Practices вендоров тут единодушны.

На фоне этих невеселых сведений особняком стоит реализация “RAID с двойной четностью” от NetApp - RAID-DP.
Будучи собственной, независимой реализацией RAID-6, полностью соответствующей определению RAID-6, данном SNIA, она принципиально отличается от собственно RAID-6 тем, что показатели на Random Write на такой дисковой группе не ухудшаются, как это характерно для “классического” RAID-6.
Если совсем буквоедствовать, то ухудшение присутствует, но в пределах нескольких процентов, против примерно 20-33% у “классического RAID-6″.
Это единственная такая реализация RAID-6 из существующих на рынке.

Это позволило рекомендовать NetApp использовать RAID-DP как тип “по умолчанию” для всех своих систем хранения.
Больший же расход дисков на “погонный usable гигабайт” компенсируется тем, что в случае использования RAID-DP мы можем использовать более длинные RAID-группы, без опаски за надежность хранимых данных. Так, например, если ранее, с RAID-4 NetApp рекомендовал использовать группы по 7+1 дисков, то в случае RAID-DP рекомендации говорят о 14+2-дисковых группах (а максимально возможно 28!), как можно видеть, количество дисков, которые мы отдаем за обеспечение отказоустойчивости не увеличивается, а надежность растет, как мы показали ранее.

Dave Hitz:
http://blogs.netapp.com/dave/2006/05/why_double_prot.html
С обычным RAID, мы рекомендуем пользователям создавать массивы RAID из 7 дисков плюс 1 parity disk. При использовании RAID-DP, мы рекомендуем создавать массив из 14 дисков, плюс 2 parity disks. Таким образом, это 2 parity disks на каждую полку с 14 дисками. При этом математика говорит, что RAID-DP на 14 дисках много, много безопаснее, чем обычный RAID на 7 дисках.

Как обещал ранее, даю ссылку на переведенный документ по внутреннему устройству 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-устройство - об этом вы узнаете в нашей следующей серии :)

В связи с нынешней активизацией на рынке SSD и Flash, возможно кому-то будет интересно посмотреть, какие продвинутые методы применяют разработчики решений, для преодоления присущей flash-memory по своей природе ограничений на число циклов записи. Ограничения сегодня уже достаточно далеко отодвинуты, но, тем не менее, совсем сбрасывать со счетов этот фактор нельзя. Основной метод, применяемый для преодоления этого недостатка, это так называемый wear-leveling. Что это, и как работает, в объяснении “на пальцах” найдено в FAQ компании Corsair (89KB, PDF).

Начиная с версии Data ONTAP 6.4 можно посмотреть текущие логи системы и забрать core dump, при его существовании, через веб-браузер по адресу:

http://your-fas-system/na_admin/logs
и
http://your-fas-system/na_admin/cores

Начиная с версии 7.2 эта опция по умолчанию выключена, вернее выключено формирование индексной страницы, так что если вы хотите попробовать, то сперва скажите в консоли:

fas> options httpd.autoindex.enable on

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

Любопытный документ найден в форумах NetApp Communities (кстати, рекомендую. Это открытый ресурс).

“Обмен дисковой емкости на зашиту данных”
Хотя это руководство и для StoreVault (S-series), но изложенное там верно и для FAS. ??з этого документа можно выяснить как превращается raw capacity дисков в usable capacity дискового пространства NetApp, и что вы получаете при этом взамен уменьшения пространства.

Trading Capacity for Data Protection – A Guide to Capacity Overhead on a StoreVault Storage System

SnapVault это “двухкомпонентная” система резервного копирования данных D2D, “с диска на диск”, основнанная на технологии снэпшотов.

Система SnapVault состоит из двух участников: системы хранения с лицензией SnapVault Primary, работающая “источником” данных, и системы с лицензией SnapVault Secondary, “получатель и хранитель” данных, в качестве которой может выступать как система NetApp FAS, так и специально разработанная для подобных применений, система Nearstore - емкое дисковое хранилище на недорогих SATA-дисках.

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

??спользование же снэпшотов в NetApp удобно в том числе и для сравнительно долговременного хранения, делая из них своеобразный “дисковый бэкап”, для мгновенного восстановления данных пользователя, в случае необходимости. Просто дайте команду snap restore [мой том] [нужный снэпшот], или же просто скопируйте из снэпшота нужные файлы, созданные в желаемый момент времени, поверх испорченных в вашем томе.

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

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

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

Пример:
У нас есть база данных размером 1GB. Мы делаем с нее ежечасный снэпшот, и этот снэпшот хранится на Secondary SnapVault-системе. Каждый час в системе накапливается примерно 2MB измененных данных. Это могут быть новые записи или изменения в старых.
При создании baseline copy, при первичной инициализации, Primary-система передает весь этот 1GB на вторичную систему. Когда передача завершена, первичная система начинает ежечасно передавать примерно 2MB в час. Однако, с точки зрения пользователя, на вторичной системе он видит, словно бы полную копию, созданную ежечасно. Видит, и может ее использовать и восстановить свой раздел и данные из нее, также как с обычным снэпшотом. Разница заключается только в том, что места на дисках используется всего 2MB*24h в день, не считая объема baseline copy, которая создается один раз в самом начале.

Подобная практика сейчас стала популярной и в традиционных системах резервного копирования, обычно под названием “forever incremental” и подобных ему, когда full backup создается один раз, а затем делается только incremental, а при необходимости восстановления восстанавливается Full и все необходимые Incremental с момента создания исходного Full, а для пользователя каждый бэкап представляется полной копией системы.
Удобство SnapVault в данном случае в том, что эта функция оказывается встроенной в систему хранения, и не требует использования внешних host-based систем резервного копирования.

Для не-NetApp систем хранения, возможно использование в качестве Primary и так называемой OSSV - Open Systems SnapVault, специального программного агента, стоящего на хост-сервере, к которому подключена сторонняя система хранения, или даже его локальные диски, и осуществляющего функции Primary SnapVault, как раассмотрено выше. Secondary SnapVault и в этом случае должен быть системой NetApp FAS или Nearstore. С помощью OSSV вы можете использовать возможности SnapVault и без необходимости использовать систему хранения NetApp в качестве Primary.

Любопытно, что сегодня в SnapVault интегрирована и дедупликация, так, если ваша Secondary-система имеет лицензию дедупликации, то процесс дедупликации будет запущен после окончания передачи baseline copy, и сможет, в ряде случаев заметно, уменьшить, хранимые на Secondary объемы baseline.

Еще несколько деталей о NFS, чаще неспецифических для NetApp, но не менее важных и интересных.

Очереди Ввода-вывода.

Если вы используете в качестве datastore LUN под VMFS, то ввод-вывод вашего ESX, неважно FC или iSCSI, будет ограничен одной очередью ввода-вывода на LUN, для всех VM хранящих свои виртуальные диски в VMFS data store на нем. Ведь ESX обращается к одному единственному LUN, с точки зрения ввода-вывода это одно SCSI-устройство, и параллельность ввода-вывода тут невозможна или очень ограничена.
В случае NFS вы можете использовать произвольное количество очередей ввода-вывода. Каждая VM, хранящая свои виртуальные диски на data store на NFS-шаре, будет иметь индивидуальную и независимую от других очередь ввода-вывода (IO queue).

VMFS LUN. Одна очередь ввода-вывода ко всем VM на data store.

NFS Data Store. Каждая VM имеет собственную очередь ввода-вывода.

Bandwidth Is not a Speed

В значительном количестве случаев при переходе с FC на NFS вы, как ни странно, можете даже выиграть в скорости.
“Как же так?” - наверняка спросите вы, “Ведь всем известно, что скорость FC это 4 GB/s, а NFS в случае 1GB Ethernet работает на 1GB/s, значит NFS просто обязана работать вчетверо медленнее!”
Ответить нетрудно. “Полоса пропускания” (англ. “bandwidth”) не равно “Скорость” (англ. “Speed”). ??, к слову, не всегда равно “Производительность” (англ. “Performance”). Смешивать эти понятия будет большой ошибкой.
Я уже писал об этой “смысловой коллизии” раньше, процитирую себя вкратце:

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

Ввод-вывод VMware ESX производится мелким блоками (4-8kb), и при этом предельно рандомно (что неудивительно для системы, хостящей множество независимых процессов множества виртуальных машин). При таком характере ввода-вывода роль играет не bandwith интерфейса, а его латентность и производительность в IOPS. А вот тут уже NFS имеет очень хорошие показатели, за счет чего и выигрывает в этих гонках. Так что, если при переходе с 4Gb/s FC на 1Gb/s NFS вы еще и выиграете в производительности, то не ищите, где же вы ошиблись. Это вполне вероятный поворот дела.

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

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