about NetApp

В группе LinkedIn “Storage Professionals” (кстати рекомендую обратить внимание на существование дискуссионных групп в LinkedIn, бывает интересно) вот уже которую неделю обсуждается тема:
SSD drives failure rates

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

I’m working as a contractor at a bank in the midwest and we have SSD’s in EMC VMAX’s for about 9 months. We haven’t seen any failures yet

I once ran a multi week attempt to burn out various vendors’ SSDs. I ran them flat out 100% random writes for about a month. Fusion IOs at something like 30k IOPs per drive, STECs / Intels around 7k. Never was able to get any of them to fail.
The Fusion IO did as many writes that month as a single SAS drive could do in over a decade.

We have approximately 150 SSD drives and have seen 1 failure during the past 12 months.

I’ve been using SSDs in a cx4-960 clariion for just under 12 months with no failures ( covering large ms sql tempdb).
From my own experience ( first shipped SSD systems 2 and half years ago), SLC SSD failure rate is in the same range as rotating drives.

Вот такие дела. Есть над чем подумать тем кто до сих пор считает, что ресурс SSD на запись ужасно ограничен, что SSD ненадежен, и при работе Enterprise Flash Drives дохнет как паленая китайская USB-флешка Kinqston.

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

Кто знает, что это грузится в самолет Pan American Airlines?

UPD: Да, это он.
Это действительно первый “жесткий диск”, устройство IBM350, выпущенное в 1956 году для использования в компьютере IBM RAMAC 305. Такой “жесткий диск” весил около тонны, имел 50 24-дюймовых диска, вращавшихся со скоростью 1200RPM, и имел скорость считывания 8800 символов в секунду. Usable space была равна 4,4 мегабайта. Цена не определена, так как IBM тогда свои компьютеры не продавал, а сдавал в аренду (их стоимость была слишком велика).

Я уже пользовался этой аналогией в одном моем полусерьезном посте ранее, из за своей "всеобщности" сравнение с автомобилем понятно и наглядно. Поэтому воспользуемся этой аналогией еще раз.

Безусловно, большинство из нас любят красивые, быстрые и мощные автомобили. Некоторые просыпаются среди ночи только для того, чтобы посмотреть, как проходит очередной заезд этапа Формулы 1, и способны часами обсуждать преимущества двигателя Феррари нового сезона над конкурентами, и крепление антикрыла Макларена. Много часов проведено в форумах автолюбителей в обсуждении того, насколько круче Бугатти Вейрон чем Ламборгини Мурселаго.

Спору нет, это все, конечно, интересно. Кто бы спорил, что Бугатти Вейрон порвет всех. В том случае, если вы имеете средства его купить и, что немаловажно, содержать.

Но когда вы соберетесь покупать себе автомобиль, я почти уверен, что интересовать вас будет не "скорость набора до 100", "масса пустого" или "максимальная скорость". Вас будут интересовать гораздо более приземленные характеристики (если, конечно, вы не относитесь к тому полупроценту, что покупают машину, чтобы по выходным гоняться на местном "Нюрнбургринге" (и только). Вас будут интересовать, прежде всего, такие параметры, как стоимость обслуживания, расход топлива при езде по "городскому циклу", доступность сервис-центров этой модели в вашей местности и время ремонта в случае поломки. Емкость багажника. Наконец, войдет ли в заднюю дверь сложенная детская коляска, и удобно ли устанавливается в машину детское кресло.

Да, это, конечно, не рев двигателя на NASCAR, и не миллискунды времени прохождения круга на "квалификации" Формулы. Это не адреналин. Но это - жизнь, это - реальная жизнь. ??менно это вас будет интересовать, если вы будете покупать машину себе.

Болид "Формулы" это, безусловно, шедевр инженерной мысли, с этим никто не спорит.
Но на болиде "Формулы" у вас не получится вывезти теще рассаду на дачу, а если вы считаете, что "это никому не нужно", то, скорее всего, это оттого, что у вас еще нет тещи, которой нужно срочно отвезти рассаду на дачу :)

Мне регулярно приходится спорить с людьми, убежденными, что "производительность и быстродействие это единственные значимые показатели системы хранения". Всякий раз, когда я в ответ возражаю, что бывают случаи (и их я бы даже сказал что в реальной жизни большинство), когда совсем не производительность в IOPS определяет успешность использования той или иной системы хранения, я снова и снова наталкиваюсь на непонимание. "Что может быть важнее скорости?"

Что же может быть важнее скорости? Например простота, быстрота и удобство восстановления данных в случае сбоя. "Стоимость хранения мегабайта". Качество и оперативность локального сервиса. Удобство и простота развертывания системы, распределения пространства по потребителям. Затраты на электропитание и охлаждение. Совокупная стоимость владения. ?? множество других, столь же "скучных" и совсем не "адреналинных" вещей.

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

В его случае, выбирая из системы с более высокой производительностью (но с поддержкой в виде "одного парня в соседней стране, в 3 часах лета на самолете") и системы с более скромной производительностью, но с хорошим сервисом, с которым уже много лет поддерживаются хорошие отношения, и удалось убедиться в их высокой ответственности, была выбрана именно последняя. ?? они ничуть не пожалели. А производительности, как выяснилось впоследствии, им хватило и с этой.

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

Есть такая известная книжка 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 лет истории этого блога. Продолжим о достоинствах на следующей неделе.

Любопытные новости притащила “утренняя почта”.

Dell, пятый по объемам продаж на сегодня, вендор систем хранения (и второй, после HP, производитель компьютеров и серверов), объявил, что покупает за 1.13 милиарда долларов путем обмена акций, довольно известную компанию 3Par.
Ранее в этом году Dell уже приобрел в июле малоизвестную молодую компанию Ocarina, разработчика интересных технологий в области систем хранения, дедупликации и компрессии, а в феврале – разработчика высокопризводительных кластерных систем NAS – компанию Exanet. Ранее, в 2008-м году, за 1,4 миллиарда, Dell приобрел компанию Equallogic и ее mid-range продукт. Кроме того, Dell много лет продает как реселлер SAN-системы хранения компании EMC, лидера рынка.
Сделку по приобретению 3Par планируется завершить до конца года.

3Par это независимая компания, производящая системы хранения уровней mid- и high-range, основной “фишкой” которых, лежащей в основе их архитектуры, является технология thin provisioning.
Thin Provisioning, напомню, это принцип, при котором физическое пространство на дисках системы хранения для созданного раздела данных занимается этим разделом данных только по мере того, как на него записываются реальные физические данные. ??спользование thin provisioning значительно повышает эффективность хранения, так как позволяет удобнее распределять дисковое пространство, а также делать oversubscribing, то есть распределять прикладным задачам на системе хранения места больше, чем его физически имеется на системе ханения, расчитывая на то, что задача не использует все выделенное место немедленно, и не “хороня” “распределенное и неиспользуемое” место в LUN-ах таких задач."
3Par была фактическим изобретателем этого принципа, выйдя с этим предложением на рынок, вслед за ней, почувствовав перспективность этого направления, такую функциональность реализовали и другие игроки, такие как NetApp, EMC, HDS, и другие.

На сегодня 3Par выпускает несколько линек своих систем хранения, некоторые со впечатляющей производительностью. К сожалению, много лет компания страдала от недостаточных объемов продаж и низкой оценки рынком. С этой точки зрения, безусловно, ее приобретение Dell-ом заметно усилит ее позиции.

Остается висеть вопрос о том, как такая покупка (как и ранее сделанная покупка Equallogic и Exanet) повлияет на отношения между EMC и Dell. По видимому Dell-у приелась роль простого реселлера (да оно как бы и не к лицу уже для пятого по размерам, и третьего по темпам роста вендора в системах хранения) и он стремится играть самостоятельную игру на этом рынке (очевидно, к неудовольствию EMC).
Dell до сих пор специализировался на “средне-низком” сегменте рынка (его собственные системы PowerVault, продукты Equallogic, и реселлинг Clariion), очевидно, что  приобретения этого года (Ocarina, Exanet и 3Par) показывают его амбиции выйти на hi-end-рынок, или, по крайней мере, в “высокотехнологичный” сегмент.

Ну, что-ж, поживем-посмотрим. С Equallogic Dell зарекомендовал себя “рачительным хозяином”. А для российского рынка это будет означать возможность, наконец, попробовать системы 3Par “в деле”, ведь не секрет, что для “энтерпрайза” отсутствие в стране саппорт-патнера практически лишает вендора шансов на продажи.

Недавно в новостях проскочил пресс-релиз NetApp, о том, что NetApp теперь поддерживает Thin Reclamation API компании Symantec. Эта новость имеет непосредственное отношение к теме Space Reclamation, которую я, кажется, в этом блоге еще не затрагивал.
Что такое Space Reclamation и зачем это вам нужно?

Задача Space Reclamation непосредственно соотносится с процессом использования так называемого Thin Provisioning.
Допустим, что мы создали в сети SAN на системе хранения LUN, на котором создана файловая система, и этот LUN постепенно заполняется данными. Мы решили использовать для этого LUN механизм Thin Provisioning, при котором место под LUN не выделяется сразу (хотя прикладная задача, использующая этот LUN "видит" сразу все заявленное место), а LUN может постепенно расти, по мере того, как на LUN записываются данные.
Настает момент, когда данные заполнили файловую систему, лежащую поверх LUN, и мы начали какую-то часть данных удалять, освобождая свободное место на диске.

Однако, у системы хранения НЕТ возможности понять, что ранее занятые блоки на LUN в созданной на нем файловой системе были освобождены. Вдобавок в современных файловых системах процесс освобождения блоков, использованных тем или иным файлом зачастую ограничивается пометкой в "таблице размещения файлов" (как бы она не называлась) блоков, занятых "удаленным" файлом, как "освобожденных", и только.

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

По этой причине график использования места на LUN, с точки зрения системы хранения, почти всегда будет выглядеть примерно так:

Как вы видите, такая ситуация сильно снижает эффективность использования Thin provisioning, так как thin-provisioned LUN всегда однонаправленно растет, и единожды занятое место уже не освобождает, даже если фактически, со временем, он опустел.

Эта проблема присуща ВСЕМ системам хранения, независимо от того, как они работают, это не специфическая проблема NetApp, она присуща любым SAN-системам хранения, на которых хранятся LUN-ы в режиме thin provisioned.  
Повторюсь: без "посредника" на уровне OS узнать о том, что происходит на файловой системе поверх LUN, о том, какие из блоков ее теперь "пусты", и, значит, можно как-то их "оптимизировать" у системы возможности нет.

Так происходит с любыми LUN, в особенности это является проблемой при наличии thin provisioned LUN, так как, уверен, вы рассчитывали на то, что после удаления данных на LUN вы сможете использовать освободившееся место под распределение данных других LUN. Но не тут-то было.

То есть просто организовать использование thin provisioning в системе хранения зачастую недостаточно. Неплохо было бы как-то отрабатывать ситуацию с удаленными на LUN данными, иначе, как мы видим, LUN всегда "однонаправленно" растет в объеме, даже если в дальнейшем его содержимое и опустошается. Это, очень часто, сводит на нет все заманчивые перспективы использования thin provisioning в продакшне.

В 2007-м году в новой версии ПО SnapDrive for Windows появилась реализация механизма "hole punching" для файловой системы NTFS. Работая на уровне OS, SnapDrive "видит" содержимое файловой системы, лежащей на LUN, и коммуницирует с системой хранения, сообщая ей, какие из блоков более данных не содержат, и могут быть безболезненно освобождены.

Запуск процесса Space Reclamation в SnapDrive, может значительно уменьшить занимаемое LUN-ом место на дисках системы хранения, если мы создали его "нефиксированного размера", без "capacity guarantee", то есть в виде, который принято сегодня называть thin provisioned.

Недавно NetApp объявил, что он присоединился к инициативе компании Symantec, разработавшей в 2008 году Thin Reclamation API для своего продукта - Veritas File System (VxFS) и Veritas Volume Manager (VxVM). Ранее о реализации поддержки этого API объявили такие компании, как 3Par, IBM, EMC (Clariion), HP (XP), HDS.

Таким образом, пользователям NetApp теперь доступен механизм Space Reclamation для двух файловых систем - для NTFS через SnapDrive for Windows и для VxFS через Thin Reclamation API.

Механизм работы в принципе довольно прост и стандартен, возможно, со временем, мы увидим его реализацию и для других файловых систем. ??спользуется стандартизованная комитетом T10 (организацией, которая занимается разработкой и стандартизацией протокола SCSI) команда SCSI-3 WRITE_SAME с флагом UNMAP. Также предложена для введения в стандарт собственно команда UNMAP, которая облегчает взаимодействие между инициатором и таргетом, в том числе и в таких задачах.

Широкое распространение этого метода откроет новые перспективы использования динамически распределяемого пространства на системах хранения.

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Continue reading ‘Usable Space у NetApp – что стоит за FUD? (часть 2)’ »

У одного из нетапповских блоггеров увидел хорошую статью, перевод фрагмента которой хочу опубликовать у себя.

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
??так, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »

Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts

Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.

В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:

fas1> options admin.hosts 192.168.1.254

Другой вариант – указать их в таком виде:

fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com

Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

В связи с приближающейся долгожданной Data ONTAP 8.0.1 со множеством плюшек и бонусов, хочу обратить внимание владельцев систем хранения NetApp FAS на то, что 8.0.х принципиально работает только на 64-bit процессорах (это связано со сменой внутренней архитектуры), а это значит, что она не пойдет на 32-х разрядных системах в линейке FAS. К 32-разрядным относятся такие системы, как: FAS2020, FAS2050, FAS3020 и FAS3050. Для этих систем следует либо остаться на “ветке” 7, которая пока еще продолжает развиваться и поддерживаться, либо провести аппаратный апгрейд.

Так, FAS3020 может быть проапгрейжена заменой контроллера существующей системы в 64-битную FAS3040, 3050 – в 3070. Но 3020, и уж того паче, 3050, это системы достаточно старые, а более современные 3040/3070 (а также системы линейки 3100) существуют уже около 3 лет. Сложнее ситуация в low-enterprise, с системами серии 2000, успешно и активно продающихся и по сей день.

Если для FAS2020 и есть теоретическая замена контроллера на 64-bit FAS2040, правда за вполне солидные для систем этого сегмента деньги, то FAS2050 пока остается “сбоку”. Есть некоторая надежда на появление аналогичного апгрейда для этого конструктива, назовем его условно “FAS2070”, но пока никаких известий нет, и многочисленные покупатели довольно удачной системы 2050 пока остаются без “восьмерки”. Ждем осени и предполагающегося, подобно прошлому году, объявления новых продуктов.