Неидеальный NetApp

Есть такая известная книжка Unix Hater’s Handbook. Решил и я завести себе такое, “ненависти к NetApp псто”, дабы не быть попрекомым безоговорочными “соплями в сахаре” по поводу Нетаппа, и собрать по максимуму все то, что “мешает нам жить” у в остальном любимого вендора и его продукта.

Начнем, пожалуй, с веб-интерфейса FilerView. Постепенно и уже с трудом выносимо устаревающий WebGUI FilerView, бывший безусловным прорывом… году этак в 2003-м. Но с тех пор, кажется, не изменялся вообще. В особенности силен контраст с тем, что получили сейчас конкуренты, взять тот же Sun OpenStorage.
Да, я знаю, что “настоящие админы используют только командную строку”, знаю и про System Manager. Но почему это должно убивать простой и понятный, доступный удаленно и под любой платформой с браузером веб-интерфейс, тем более, уверен, написать новый, красивый, современный, со всеми новыми удобными фишечками и вообще eye-candy веб-интерфейс это задача для пары фрилансеров на месяц работы?

Долгожданная “восьмерка” так и не принесла столь же долгожданной интеграции ONTAP ‘G7’ и ONTAP GX. В результате мы имеем фактически всего лишь два продукта (отдельно – cluster-mode, и отдельно 7-mode) устанавливающихся из одного дистрибутива. С разной функциональностью, несовместимых и не “переключающихся” между режимами.
Конечно я знаю о необходимости поддержки огромного парка старых систем, работающих на прежних версиях,  и все прочее. Но, ребята, злосчастный Spinnaker и его наследие “пережевывается” компанией уже около 6 лет! Да, NetApp был одним из первых, кто начал заниматься “облачными хранилищами”, и увидел их перспективы задолго до того, как о них заговорили все. Но он также фактически последним вывел на рынок реальные “массивно-кластерные” системы (а некоторые клиенты так их и не дождались, так, например, MySpace в свое время ушли с NetApp на Isilon именно по этой причине). Многобещающее приобретение компании Spinnaker много лет не давало никакого заметного “выхлопа” в продукте, а вышедший на рынок Data ONTAP GX имел множество ограничений, и массовым, увы, не стал, оставшись весьма нишевым продуктом.

О, о “восьмерке” говорить можно долго. ;-| Если вы планируете переходить на G8 ‘7-mode’, продумайте все до мелочей. Зачастую “обратного хода” не будет. Переход на долгожданные “длинные”, 64-bit aggregates это “дорога с односторонним движением”. Существующие “32-bit” аггрегейты никак не превращаются в новые, 64-bit. Да, только забэкапить, остановить, убить старые, вместе со всеми томами и LUN-ами на них, создать новые, пересоздать на них обратно тома и LUN-ы, и восстановить содержимое. Звучит просто для демо-лабы. Но, подозреваю, предложи вы такое энтерпрайз-админу с несколькими mission-critical стораджами, весьма вероятно он вас попытается придушить куском патч-корда.
И, да, “если что-то пошло не так”, вернуться на “семерку” вы не сможете.

И, кстати, да, перейти вы сможете только в случае если вы в свое время купили “подходящее” оборудование. Купили FAS2050 и планируете наращивать его емкость, потому что контроллерной мощности вам хватает? Для вас нет ONTAP 8. И не будет. Причем и FAS2050, и FAS2020 по прежнему продаются, и вполне себе recent hardware, по крайней мере с точки зрения продавцов NetApp.
Предмет обоснованной гордости нетапповцев, полная сквозная совместимость продуктовой линейки, простота апгрейда и длительная поддержка в софте даже “старых” систем и данных на них, увы, в прошлом.

Серия FAS2000 вообще выглядит “бедным родственником”, впрочем, по понятным причинам, для вендора, но нам, пользователям, от этого не легче. Мы купили FAS2050, с 20 дисками SAS, а теперь, спустя пару лет, хотим мигрировать на FAS3140 с полкой DS4243 с дисками SAS, можем ли мы использовать уже заполненные данными наши 20 дисков с системы FAS2050, для минимизации затрат на миграцию, да и ведь они тоже SAS, и стоят немало? Не можете. Конструктив дискового “фрейма” несовместим. Можете попробовать продать их на eBay, удачи.

Очень неприятен “заговор молчания” вокруг “проблемы фрагментации WAFL”. Никаких комментариев. Никаких официальных цифр. Кормитесь слухами (ну и, конечно, “радостными”  пугалками довольных конкурентов!). 
Нам, пользователям NetApp, нужен, наконец, официальный technical report и best-practices на этот счет! Они есть по куда менее значительным и существенным аспектам эксплуатации системы, они должны быть и о путях решения этой проблемы.
Нужно открыто и ясно сказать все, что компания думает об этом, о путях возникновения, избежания, и реальном влиянии fragmentation и reallocate на производительность на конкретных примерах и в открытом тестировании. Это единственный путь свести к минимуму результаты FUD конкурентов на этот счет!

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

Совершенно непонятна история с VTL и попыткой покупки Data Domain.
У NetApp существует (теперь уже стоит говорить “существовал”) свой собственный, и, судя по словам попробовавших, довольно неплохой продукт NetApp VTL, полученный вместе с приобретенной ранее компанией Alacritus. Возможно он был неидеален. Наверняка там было куда расти. Но он уже был, работал, развивался и, кстати, неплохо продавался. После довольно долгих мытарств (свыше года разработки) на этой платформе была реализована технология дедупликации, причем была создана иная, нежели на FAS система, с рядом улучшений (например с компенсацией “смещения” содержимого идентичных блоков данных, часто встречающегося в резервных копиях), в перспективе с возможностью имплементации онлайн-дедупликации, вдобавок к уже сделанной “оффлайн”.
Но покупка срывается, Data Domain уходит к EMC.
Вскоре после этого NetApp объявляет о прекращении дальнейших разработок в линейке VTL, и, фактически, отказывается от этой линии в своем продуктовом портфеле.
Допустим, DDUP это отличная технология, превосходящая VTL. Хорошо. Но VTL уже был, продавался, у него были свои клиенты и свой сегмент рынка, недавно были завершены разработки новых, многообещающих софтверных фич. Не удалось купить DDUP – ну что-ж, надо продолжать разрабатывать свою систему, пока она не станет такой же хорошей. Но почему неудача покупки новой технологии должна следом вызывать отказ от другой аналогичной, уже успешно разрабатывающейся в компании,  и продающейся несколько лет – я не понимаю, и объяснения нисколько не убедительные.
И что будет столь же “убедительно” и “мотивированно” будет вдруг похоронено следующим?

“За кефир отдельное спасибо всем” (с) ММЖ
О веб комьюнити, и NOW. Это, как говорится выше, “отдельное спасибо всем”.
Как вы знаете, до недавних пор, до появления сommunities.netapp.com, единственным веб-ресурсом NetApp в интернете был NOW – NeApp On Web. Пусть он уродлив не слишком красив внешне (примерно как FilerView), и его обходит стороной уже третий, если не четвертый, “фейслифтинг” собственно вебсайта NetApp, но на нем можно найти документацию, а также статьи Knowledge Base, и, до открытия communities, примитивный простой, но функциональный форум. Но.
Только если вы имеете в NOW логин. Для полноценного доступа в NOW вам нужен логин, причем логин не просто  “посетителя” (который создается “вручную” персоналом и, зачастую, за неделю времени!), с которым вы увидите, фактически, только первую страницу, при переходе с любой на ней ссылке видя  сообщение о недостатке прав доступа.
Я правда не понимаю, что такого секретного нельзя показывать посетителям “невладельцам” (например “пока не владельцам”) систем хранения и не сотрудникам компаний-партнеров в текущей документации на Data ONTAP, в статьях Knowledge Base или примитивном форуме пользователей.
Почему, даже не купив ни одного продукта компании Microsoft, пользователь может войти и прочитать и статьи в Knowledge Base, и документацию в TechNet, но ровным счетом ничего (кроме как разлогиниться) не может в NOW?
Что за секреты там хранятся? Я лично не нашел ни одного.

Ах, да. Если вы создали (вам создали) логин в communities и NOW, привязанный к e-mail, а потом, по той или иной причине вы доступ к этому e-mail потеряли (простейший пример – уволились, перейдя в другую компанию), то перенести ваш логин на другой e-mail нельзя. Бросайте свои завоеванные рюшечки, звездочки и пойнты за ответы и помощь коллегам, записи в блоге и собранные букмарки своего привычного и “прокачанного” аккаунта и начинайте снова, с новым логином.

Ну и напоследок.
Компания – живой организм. Люди приходят и люди уходят, это естественная жизнь. Некоторые из сотрудников NetApp ведут на сайте компании свои блоги, и это замечательный источник информации о продуктах компании. За несколько лет такие блоги часто становятся источником очень полезных статей, на многие из них ссылаются извне, используют изложенные факты в дискуссиях, и так далее.
Но скажите мне, какого, извините, черта, полностью немедленно удалять содержимое интереснейшего и популярного блога, если его человек в компании больше не работает?
Кажется еще совсем недавно я переводил для своего блога серию статей технического директора NetApp Костадиса Руссоса об устройстве WAFL, и вот теперь он ушел из NetApp (в компанию Zynga, кто понимает шокирующую крутизну поворота карьеры;), а на месте его блога открыватся пустая белая страница. И это совсем не единичный пример.
Идите, мол, можете попробовать в archive.org найти, он нам больше не сотрудник, и написанное им за несколько лет мы грохнули.

UPD: Ах да, забыл совсем. Non-transferrable licenses. Как вы, наверное, знаете, стоимость систем NetApp складывается из стоимости железок, и стоимости лицензий на те или иные софтверные фичи, которые включаются ими, например на доступные пользователю протоколы, FlexClone, SnaopMirror и прочее. Очень часто стоимость лицензий это добрая половина, а иногда и до двух третей цены системы. Однако эти лицензии - “непереносимы”. Вы купили систему за стотыщпицот долларов, спустя пару-тройку лет хотите ее продать, и у вас есть покупатель. Однако вы не можете официально продать с системой лицензии, купленные вами за полновесные, и заплаченные NetApp, кстати, доллары. А без лицензий эта система - бессмысленная неработоспособная железка, к которой можно подключить только консоль. NetApp считает, что покупатель юзанной системы должен прийти к нетапповским сейлам и заново купить на нее все лицензии, повторно. И еще раз заплатить. При этом рынок юзаных нетаппов, и, разумеется, “transferrable licenses”, существует, и довольно широк. Но NetApp предпочитает закрывать глаза и делать страусиный вид, что этого не видит.

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

15 комментариев

  1. Nrs:

    спасибо romx. по поводу документации - сам так же столкнулся, был сильно удивлен. пришлось искать на торрентах. но от NetApp не откажусь, у других косяки еще больше и ширше

  2. anvarich:

    Про недостатки читать интересней. С удовольствием прочитал бы такую же статью про других вендоров EMC, HP etc

  3. downpour:

    Меня, сильно напрягло, что вся документация разбита на разные документы, стало проще скачать редбук, где в одном документе есть все и сразу

  4. Александр:

    anvarich, недостатки EMC… Ооо… их так много и поверьте описные тут недостатки NetApp не такие уж страшные :)
    Поверхностно про EMC:
    1. абсолютно не умеют делать SnapShot’ы
    1.1 количество снапшотов на Clariion всего… 8 (ВОСЕМ!) для одного LUN’а и столько же клонов и самое интересное, что снапшоты и клоны на Clariion нельзя делать для Thin LUNs - virtual provisioning (thin provisioning в терминологии NetApp)
    1.2 Чтобы сделать снапшотн на EMC… пожалуй коротко не получится, но порядок действий внушителен :)
    1.3 Ещё прикольно как они делают снапшоты: новые блоки пишутся в ИСХОДНОЕ место, а СТАРЫЕ копируются в Snap Pool т.е. прежде чем блок запишется на LUN он должен подождать пока старый переедет в другое место… чувствуете разницу? :)
    2. делать клоны на EMC это сплошное мучение
    2.1. Колны на EMC - это АД! Сделано все наоборот по сравнению с NetApp… мама дорогая… во-первых он будет делаться КУЧУ времени (зависит от размера и загрузки) т.е. они делают ПОЛНУЮ синхронную копию исходного LUN’a (… source LUNs and their clones must be exactly the same size.), причем синхронизация идет ПОСТОЯННО, а потом когда захочется этот клон использовать его нужно разорвать с исходным LUN и эта операция может занять также кучу времени т.к. для того чтобы закрыть сессию запись в исходный LUN прекращается, пока не клон не докатится до эквивалентного исходному LUN состоянию. Причем если идет интенсивный ввод/вывод с исходным LUN’ом, то колон может вообще не отцепиться - ржака, да :))))) Для этого там есть хитрущий параметр с вообще не говорящим названием “Quiesce Threshold (sec.)” с которым можно “поиграться” если клон не отцепляется :))))
    3. B и самое, самое, прикольное - это КЭШ! Например, Clariion CX4-240 8Gb кэша на два SP и в ЭТОЙ же памяти содержится… внимание… операционная система - Windows XP и чем больше функций (SnapView, QoS, etc.) подключаете, тем больше памяти она ест :)))

    P.S. про HP ничего, к сожалению, сказать не могу т.к. не работал с ними и не знаю их :(
    P.P.S. прости, romx, появились таки в твоем блоге сранялки… это ещё не все… продолжение следует… ещё VMax на очереди :)))

  5. Альберт Салман:

    Проблеме фрагментации WAFL и reallocate посвящено немало в курсе PAD (Performance analysis on Data ONTAP) явно и вообще говоря дофига неявно в нем же. Но опять же не было никакой статистики, что мол обычно “вот так вот хреново становится за такое то время для таких то видов данных”.
    Такое “скрытие” информации в некоторой степени обусловлено загребанием бабла за курсы и анализы производительности проводимые самим NetApp по запросам клиентов.

  6. Owl:

    Про кэш на EMC верно написано.
    У меня есть в демо массив CX3-10 у которого 1Гб на контроллер.
    Так вот из них 700Мб занимает операционка, что дает возможность поставить лишь 64Мб кэша на чтение и 128Мб на запись ;)
    А ведь это голая CX3-10 в которой нет НИЧЕГО из софта ;)

  7. villain:

    Даже докупив на нее весь софт который потянет CX3-10 у тебя так же будет 64/128. Не вижу как установка софта будет влиять на размер именно кеша в CX.

  8. villain:

    Снапшоты у EMC просто другие. Например такое устройство позволяет получать размер LUN и размер изменений больше чем размер исходного LUN.

  9. Привет, Алексей ;)
    Не понял в предыдущем комменте что предполагалось сказать, и что такое “такое устройство”?

  10. villain:

    Привет Роман 8-) (почитываем вас, почитываем)

    “Такое устройство снапшотов”.

    Наверное сказывается мое “блочное” мышление 8-).

    Попробую сформулировать подробнее.

    Структура WAFL/ZFS/BTRFS/etc очень интересно, позволяет легко создать/управлять снапшотами. Но проблема в том, что размер изменений ограничен размерами структуры (массив дисков с WAFL) поверх которой создается структура данных.
    Например:

    Внутри большой системы есть массив дисков с WAFL (допустим 8 дисков по 300G - RAID-DP - грубый полезный объем 1.8 Тб)
    На этом массиве есть LUN. Может ли объем LUN+несколько снапшотов (реальных изменений) быть размеров больше чем 1.8 Тб?

    “Пример - Сферический конь в вакууме” - большая база (продуктив работает непрерывно) + поэтапное обновление и сохранение всех этапов для отката на любую стадию (проверка миграции на новую версию продукта)

  11. Owl:

    Дла начала, на этом “массиве” - агрегате, есть - volume, внутри которого есть LUN.

    Может ли объем LUN+несколько снапшотов (реальных изменений) быть размеров больше чем 1.8 Тб?

    Если я правильно понял, то да - может, если LUN - thin provision.

    А вообще чудес не бывает: если реальные данные ЕСТЬ - значить для них нужно место.

  12. villain:

    Опять же можно найти патерны нагрузки ввода/вывода для которых в блочных устройствах можно получить заметный прирост. Например для большого кол-ва random read строится массив дисков, режется LUN необходимого размера (и размер LUN будет достаточно небольшой от размера массива ~ 10%, все остальное редко используемое хранение - ээээ хранение ISO 8-))) и получаем прирост производительности (народ пишет что до 10-20%) за счет локализации области позиционирования головок на винтах.

    В WAFL мы такого не получим (да да помню про превращение random write в sequential write 8-))

  13. villain:

    Owl:
    Агрегат у нас всего 1.8 Тб (8×300 RAID-DP)

    Я сразу сказал что это “сферический конь” 8-) - у EMC тормоза начнутся еще те при такой загрузке 8-). Но в reserved LUN данные будут переноситься и именно он уже будет являться узким местом при росте объема, но его можно спланировать отдельно от основного. А данные реальные есть и есть изменения - т.е. база после изменений не вылазит за 1.8 Тб (но вот все шаги уже вылазят - допустим база 1 Тб и каждое изменение на диске ~250-300 Гб - последовательно таких изменений - 4 , на последнем тест и commit 8-))).

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

  14. Andrey:

    Не знаю что такое thin provision, но если фактический обьем снепшотов не вылазит за зарезервированное место под снепшоты или свободное место на volume, то будет работать на NetApp. У нас FAS30×0.
    1Tb данные, 50Gb + 100Gb + 150Gb + 200Gb (размер снепшотов).

  15. А еще убивает тех.поддержка! Которая, вероятно, считает, что раз ты купул железку за пару миллионов рублей, то должен быть счастлив самим фактом её обладания. Руководств пользователя в комплекте нет, её нужно качать. Регистрацию на сайте нужно вымаливать, задействуя все мыслемые и немыслемые методы. Более ублюдочного подхода к конечному пользователю нигде не видел.

Оставить комментарий

20/0.150

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.