about NetApp

Костадис Руссос (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 была командная строка в консоли администратора, доступная по телнету или ssh для любой системы NetApp.
Так как, исторически, главной "целевой аудиторией" для первых систем хранения NetApp были системные администраторы UNIX, было решено сделать консоль администрирования настолько похожей на стандартную UNIX-консоль, насколько это возможно.
??менно потому, что консоль NetApp настолько "юниксподобна", это год за годом порождает слухи в "хитро спрятанном линуксе инсайд" хотя внутри NetApp и совершенно не UNIX, или по крайней мере нечто, совсем отличное от известных большинству UNIX-систем. Давным-давно я уже писал, что именно находится внутри, интересующиеся могут сходить в тот пост.

С расширением "аудитории" NetApp возникла потребность в создании чего-то более GUI-образного и "интуитивно-понятного", и в 1996 году, 13 лет назад, появился веб-интерфейс FilerView, на тот момент один из первых такого рода на рынке систем хранения.

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

Повторюсь, для 96 года это был прорыв. Однако с той поры прошло уже, страшно подумать, 13 лет, выросло уже, по сути, новое поколение "сисадминов". Веб-технологии развивались стремительными шагами, и интерфейс FilerView стал выглядеть, деликатно выражаясь, несколько архаично. Да он по прежнему прост и функционален, по прежнему делает все, что необходимо, но уже совсем не "радует глаз".
Зачастую это даже стало вызывать определенное отторжение у новичков. Встречают в мире по прежнему по одежке.

В недрах NetApp довольно давно велись работы в этом направлении, так, standalone GUI под названием StorVault Manager получило семейство StorVault (S-Series), выходили специальные "мастера" начальной устрановки систем FAS под Windows (QuickSetup Wizard и FAS Easy Start Wizard), а также продукты Protection/Provisioning Manager, "гуизирующие" определенные фрагменты общего процесса.

?? вот, наконец, все вместе, в новом продукте для управления вашими системами FAS: NetApp System Manager.

Continue reading ‘NetApp System Manager’ »

Довольно часто админам, особенно тем, у кого в подчинении находятся несколько систем NetApp, приходится решать задачу переноса информации между системами хранения.
Например на файлереА у нас терабайт домашних папок, которые понадобилось перенести на новый файлерБ, чтобы освободить место на файлереА.
??ли перенести данные с одного ресурса на другой внутри той же системы.

Казалось бы, чего проще: монтируем обе шары на какой-нибудь сервер, запускаем на нем копирование и оставляем на ночь.

Но нормального админа грызет сомнение, но ведь контроллеры NetApp это “обычные серверы”, почему они не могут сами между собой договориться и перекинуть все хозяйство своими силами?
Могут.

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

ndmpd on

и выполните в консоли команду:

ndmpcopy -sa root:password -da root:password filer01:/vol/vol1/share1/tree1/ filer02:/vol/vol2/share2/tree2

где -sa root:password, соответственно, имя и пароль рута на source filer01, -da - на destination filer0, а далее указаны пути копирования для источника и получателя.

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

Можно копировать как внутри одной системы:

myhost> ndmpcopy -sa username:password -da username:password myhost:/vol/vol0/source_path myhost:/vol/vol0/destination_path

или короче:

myhost> ndmpcopy /vol/vol0/source_path /vol/vol0/destination_path

так и с одной системы на другую:

myhost> ndmpcopy -da username:password /vol/vol0/source_path remotehost1:/vol/vol0/destination_path

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

myhost> ndmpcopy -sa username:password -da username:password remotehost1:/vol/vol0/source_path remotehost2:/vol/vol0/destination_path

PS. ACLs конечно же при этом также переносятся корректно.

Многие админы Windows Servers уже знают и используют новые возможности “коммандлайнового интерфейса Windows” - PowerShell.
Кто еще не вникал - самое время вникнуть: MS Official, Wikipedia, Blog.

Для уже знакомых с PowerShell укажу интересную разработку, позволяющую управлять системами хранения NetApp через PowerShell, с использованием ONTAP Management SDK.

Найдено тут: PoshOnTap
Просмотрите также и прочие темы этого автора в блоге, можно найти любопытного.

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

Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются.

Целью же моего предыдущего поста была попытка донести мысль, что в случаях, когда то или иное дорогостоящее решение не дает существенных, сравнимых с затратами на него результатов, использовать его неразумно и расточительно. Те же деньги можно потратить с гораздо большим результатом иным способом. ?? этих способов немало.
Затраты должны быть соизмеримы, и решения должны быть соразмерны задачам.

В прошлом своем посте я не столько пытался “опустить” FC, сколько донести мысль, что когда клиент покупает на “последние деньги” какой-нибудь Xyratex или Infortrend (все совпадения с реальным торговыми марками случайны;), при этом наполняет его дисками c “митина”, потому что “нет денег на родные”, но при этом собирается половину, а то и две трети цены массива потратить просто на “провод” для подключения, то это, мне кажется, крайний случай несбалансированности.

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

По моему мнению, FC в entry (да зачастую и не только entry) level это типичный пример гаражного тюнинга и “синих писалок” в IT. Это эффектно, но, как и дырки в глушителе, выдающие мощный рев на светофоре, нисколько не помогают с него уехать быстрее.

Почти всегда, начиная разговор с клиентом по поводу использования iSCSI вместо Fibre Channel, раз за разом я сталкиваюсь с одним упорным возражением:

“Ну… хм… Это же медленно!”

Ну, казалось бы, очевидно: FC это 4Gb/s, а iSCSI - 1Gb/s, “один” ведь в четыре раза меньше, чем “четыре” ведь так?

Давайте разберем что здесь на самом деле “медленно” и медленно ли.

Для определенности давайте рассматривать какую-нибудь реальную задачу.

Вот пример:
Требуется система хранения данных для консолидации данных 4 серверов, 1 файловый сервер и 3 сервера баз данных. Необходимо обеспечить двухпутевое отказоустойчивое подключение.

Но сперва немного теории.

Я уже писал на тему странного спутывания в восприятии совершенно разных параметров канала передачи данных: “полосы пропускания” (анг. “bandwith”) и “скорости” (анг. “speed”).
Для интересующихся подробностями просто сошлюсь на ранее опубликованный пост, а остальным перескажу вкратце.
“Скорость” канала передачи данных равна скорости света в соответствующей среде, и она постоянная, вне зависимости, используем мы 10Mb/s Ethernet или 16GB/s Infiniband.
Переводя на аналогии из “повседневной жизни” это ограничение скорости на дороге - 100 km/h.
Все автомобили по дороге передвигаются с разрешенной скоростью, и ее не превышают по причине физического ее ограничения на уровне физических констант.

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

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

Если скорость считывания и записи сервера с системы хранения, например, не превышают 10 Мбит/с, то совершенно неважно для быстродействия, используете ли вы 100Mbit/s Fast Ethernet, FC, Infiniband, или подставьте_любой_баззворд_из_презентации.
Если вы не используете даже имеющуюся полосу пропускания целиком, то расширение ее “неиспользуемой части” в 10 раз не приведет к сколь-нибудь значимому увеличению реального быстродействия системы.

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

Вернемся к нашей практической системе хранения для 4 серверов.
В ходе предварительного анализа производительности, наиболее нагруженный сервер баз данных показал, по данным Windows Performance Monitor, следующие показатели:

Disk Read bytes/s 2700902/Average 63587550/Max
Disk Write bytes/s 736811/Average 1616167/Max

То есть, самый нагруженный сервер системы, в максимуме нагрузки, достигал порога чтения всего, примерно, в 60-65 мегабайт в секунду!
Это всего лишь (в пике дневной нагрузки, прошу заметить!) около 55-60% от полосы пропускания одного интерфейса Gigabit Ethernet, или, в случае типовой нагрузки в 2.5-3MB/s, всего около 2-3% от полосы пропускания GigE!

Возможно в данном случае мы упираемся в предел возможности локальных дисков серверов, на смену которым призвана встать система хранения, и сервер имеет большой запас по производительности, если мы обеспечим ему широкую полосу пропускания для данных? Но нет, показатель Disk Read/Write Queue редко когда превышает значение 8-9, что означает относительно слабо нагруженную дисковую подсистему, значит в дисковую производительность сервер практически не упирается.

??так, давайте посчитаем. В случае нашей рассмотренной выше небольшой IT-системы из четырех серверов, в случае выбора FC нам необходимы:
1. по два однопортовых или по одному двухпортовому FC HBA на каждый сервер - 8 однопортовых или 4 двухпортовых (QLogic QLE2462 2port - 700$ * 4 = 2400$)
2. два FC-коммутатора (недостаточно встроенных FC-портов для подключения всех 6 линков) допустим, пусть это будут массовые и недорогие Brocade 200E - 4000$ * 2 = 8000$.
3. Лицензия на FC (в зависимости от выбранного массива цена варьируется, например для системы типа FAS2050 это около 1200$ для одноконтроллерной и 2400$ для двухконтроллерной, отказоустойчивой, “кластерной” системы)
4. ПО поддержки многопутевости (стоит заметить, что в поставке Windows средство обеспечения многопутевости MPIO не поддерживает FC, только iSCSI, и использование MPIO с FC требует установки дополнительного программного модуля, так называемого DSM, обычно предлагаемого поставщиком решения системы хранения, он недорог, но тоже не 0$)
5. Кабеля FC optical LC-LC для подключения серверов к коммутаторам (8 шт) и коммутаторов к массиву (2 шт) (LC-LC optical 5m - 50$ * 10 = 500$).
6. затраты на монтаж и настройку (варьируется).
Кажется ничего не забыл :)

??того, нетрудно видеть, только на возможность использования протокола Fibre Channel мы потратим по меньшей мере около 12-15 тысяч долларов! При этом, как я показал выше, эти 12 тысяч совершенно не увеличат производительность получившейся системы. Они потрачены исключительно “на понты”, на возможность бросить в разговоре с коллегами “а, мы тут файбер ченэл себе прикупили”. :)
“Хороший понт дороже денег”, не спорю. ;) Но 12 тысяч это 12 тысяч. Тем более в наше непростое время на дворе.

Но если бы мы использовали эти, вполне существенные деньги, на что-нибудь действительно дающее реальный эффект, например на пару дополнительных серверов для других задач, премию сисадминам оплату услуг хорошего программиста-оптимизатора баз данных, или, например, в случае системы хранения данных, на дополнительные 10-12 дисков, то за те же деньги мы бы получили (см. ранее про IOPS дисков) систему хранения по меньшей мере на 1800-2500 IOPS быстрее!

?? только за счет отказа от “крутого”, “понтового”, но избыточного, и поэтому совершенно “неполезного” в данном случае Fibre Channel.

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

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

Я уже поднимал в этом блоге тему оптимальных решений той или иной задачи. К сожалению, в нашей стране так до сих пор и остались пустыми словами понятия “стоимости владения”, которым так много внимания уделяется во всем мире.
Ну это наша традиционная болезнь. Чтобы уменьшить фотографию с пьянки нет лучше средства чем Adobe Photoshop CS3, а eсли ставить “венду” - то только Datacenter Edition. “Красть - так миллион, … так королеву” :)

Компания, на которую сваливаются нежданные IT-бюджеты ведет себя как “новый русский” из анекдотов в магазине: “Принесите мне все САМОЕ дорогое! Плачу наличными!”. ?? если бы в самом деле платил :) На деле понты не дают возможности купить не САМОЕ дорогое, а на дорогое денег… как бы… не особо-то. :) Особенно сейчас.

Однако предложение: “Ну зачем вам вот это вот, оно для вас сейчас совершенно ни к чему, вы его просто не сможете использовать в полной мере, а стоит оно тут ого-го, возьмите вот так вот, и все будет работать точно также” воспринимают не менее чем как оскорбление. “Как! Мы биг энтерпрайз (ну по крайней мере хотим ими быть), а вы нам какой-то едва ли не entry level подсовываете!”

Простой пример из жизни. У клиента сравнительно небольшая IT-система, в которой два сервера SUN, файлы (и в перспективе базу Oracle) которых надо бэкапить. Есть небольшая ленточная библиотечка для этого, будет еще какой-то дисковый массив. В общем все достаточно экономично.
Предполагается использовать для этого Symantec NetBackup.
Ну тут, в принципе, все просто: один NBU Server, два NBU Client for UNIX и лицензия на Tape Library, 1 Drive.

Затык один: клиент хочет “чтобы бэкап шел по SAN”, чтоб все “как у больших”.
Ну, если “как у больших”, то тогда нужны уже версии Enterprise для сервера и клиентов, только в них есть SAN Backup и SAN Client.
А это совсем другие деньги, тоже как для “больших”.

??того, в рекомендованных ценах от Symantec - более 39 тысяч долларов для всего двух серверов!
?? каждый следующий подключенный сервер обойдется как минимум в 15 тысяч!
?? это только за нашу прихоть “бэкапить по SAN” и больше ни за что (больше никакие другие функции Enterprise Client/Server использовать не планируется).

Но если мы не боимся, что нас “пацаны засмеют”, и воспользуемся стандартным бэкапом по сети (а ведь для бэкапа по сети, если уж мы ни в какую не хотим бэкапный трафик пустить в общую LAN, мы запросто можем поставить выделенный гигабитный сетевой адаптер), то нам будет достаточно версий Standard, и, для того же самого, всего около 14 тысяч (и плюс 1700$ за каждого дополнительного клиента).

А если мы еще чуть внимательнее отнесемся к экономии денег, и тщательнее посмотрим на прайс Симантека то обнаружим там такую чудесную вещь, как NetBackup Starter Kit, в который входит “NBU Server for UNIX Tier 2 + Tape Library License + 5 NBU Clients”, то есть все то что нам надо, плюс еще три клиента на будущее, в запас, и за все про все - 6000 долларов!

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

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