about NetApp

Сокращенный перевод поста Chris Lionetti, Reference Architect – Microsoft Solutions Engineering

Этот пост рассматривает проблему Unrecoverable Error Rate (UER), «Уровня невосстановимых ошибок» на жестких дисках.

Диски типа SATA оптимизируются по соотношению GB/$ и GB/Watt, в то время, как диски с интерфейсом FC и SAS по параметрам IOPS/$ и IOPS/Watt. Это означает, что в плане плотности записи и механики, диски типа SATA решительно отличаются от дисков FC/SAS *1. Диски FC/SAS трехлетней давности имеют Unrecoverable Error Rate равный одному блоку на 10^15 бит данных (UER15). Диски SATA имеют этот параметр равный 1 блоку на 10^14 бит данных (UER14), что означает, что один блок (512Bytes) может быть потерян в среднем каждые 11TB считанных данных. Для UER15 это означает 1 блок каждые 110TB данных, и UER16 значит 1 блок каждые 1100TB пространства.

Давайте используем те же 9-дисковые наборы, что и в первой части поста. Берем 9-дисковый RAID 5 (8+1), 10-дисковый RAID DP/6 (8+2), и 16-дисковый RAID 10 (8+8). Предполагаем, что мы используем ту же инфраструктурную схему, при которой используется суммарно 800 дисков с данными.

Также возьмем за предположение величину отказа в 3%. Это означает 27 ребилдов для RAID 5 (см. предыдущую статью почему так). Допустим, что мы используем диски на 1TB, что означает, что когда в нашей дисковой инфраструктуре случается отказ (по нашим расчетам это может происходить до 27 раз в год) у меня есть шанс 8 из 11 (72% вероятность) что я получу ошибочно прочитанный UER-блок во время ребилда. Так как в случае  возникновения UER она воздействует на весь страйп в наборе RAID 5, она влияет на объем данных, равный Stripe Element size * stripe size. Это означает, что вы можете получить до 64KB x 8 = 512KB поврежденных данных посреди вашего датасета, не узнав об этом. Хорошая новость в том, что, скорее всего, вы используете более надежные диски.

Если вы используете так называемые «enterprise class» диски вместо недорогих дисков «Desktop class SATA», то вы получаете диски с уровнем UER15. Такие более высококачественные диски, с более высоким UER, будут повреждать данные всего в 7.2% случаев во время каждого ребилда. В случае использования дисков FC 15K/10K, эта величина понизится до 0.72% во время каждого ребилда.

В случае RAID10, опасность гораздо ниже, так как ребилд производится всего с одного диска, а не с целой их группы. Смотрите таблицу.

Данные в таблице берут за основу параметры: 3% AFR, 8 дисков данных, и рассматривают вероятность для каждой операции ребилда.

Диски типа Enterprise SATA обычно приближаются к величине UER15, в то время, как в случае дисков FC и SAS 15K RPM всегда говорят о UER16.

Скрытые проблемы на Enterprise SATA.
Аргумент, который всегда приводится, это что SATA имеют теперь тот же уровень ошибок, что и «enterprise drives». SATA на протяжении последних лет постепенно улучшают свои показатели, с UER14 до UER15, но, одновременно с этим, учетверяют свой объем. Стали ли диски боле надежными? Да, но не в 10 раз, как вы могли бы подумать, глядя на техспеки. За то же самое время диски enterprise FC улучшили показатель надежности с UER15 до UER16, достигнув при этом примерно половины емкости от дисков SATA.

Существует также некая возможность в дисках SATA, которая позволяет индустрии дисков SATA достигать уровня UER15. Эта возможность называется «heroic recovery» *2. Этот вариант восстановления ошибочно считанных данных при чтении означает, что диск прочитывает очень большой фрагмент данных и пытается восстановить неустойчиво прочтенный блок с использованием избыточности, чтобы потом переписать его куда-нибудь в другое место. Результатом замедления работы при «heroic recovery» может быть то, что диск перестает вовремя отвечать на запросы, и, в результате, вываливается из RAID.

Большинство (если не все) контроллеров RAID выключает на своих дисках «heroic recovery». Вопрос, ответ на который невозможно получить ни от одного вендора жестких дисков, это то, измерен ли UER этих диско с выключенной heroic recovery? Если вы утверждаете, что heroic recovery блока может восстановить данные с 9 из 10 неустойчиво читающихся блоков, то выключение этой возможности означает снижение для диска UER15 до UER14. Я включил в график данные как для UER14, так и для UER15, ваши диски будут располагаться где-то между этими двумя. Этот график показывает как оптимистичные, так и пессимистичные оценки вероятностей в RAID 5 и RAID 10 для объемов ваших данных, могущих быть поврежденными на протяжении года.

 
Выводы
У вас есть две возможности избежать неприятностей. Вы можете либо выбрать использовать RAID6, либо использовать диски с UER16. Этот пост написан не с целью продать вам диски SATA или FC, но лишь только помочь вам осознать опасности использования RAID5, а также опасность использования дисков SATA не имея способ смягчить возможные последствия. Вот в чем смысл нашего сегодняшнего заголовка. Все эти три понятия - сказочные.

(прим. romx: долго подмывало вместо Деда Мороза написать Честный Милиционер, или что-то в этом духе. В оригинале был Easter Bunny, «пасхальный кролик»)

Самое главное, что вы должны уяснить, дочитав это пост, это то, что больше нельзя доверять RAID 5. У вас есть сравнительно небольшой риск того, что ваши данные будут полностью потеряны, но существует гораздо более высокий риск того, что поврежденные данные приведут к замедлению работы, если попадутся в момент операции ребилда.

–
*1 Willis Whittington – WINHEC05 presentation on enterprise drives
*2 http://www.wdc.com/en/products/products.asp?driveid=403 Читайте про time limited recovery. Целых 7 секунд!. Эта проблема существует по всей индустрии SATA, а не только у Western Digital.

По некоторым признакам, кроме PAM, все же будут у NetApp и обычные SSD в виде “дисков”.
Некоторе сведения об этом найдены тут: SearchStorage

Третьим шагом будет поддержка SSD в самих дисковых массивах, которую сейчас предлагают все крупные производители. “Позже в этом году мы проведем сертификацию дисков SSD в дисковых полках”, сказал Jay Kidd (NetApp’s Chief Marketing Officer). “Вы сможете добавить их к существующим системам, возможно с помощью дополнительных дисковых полок, которые поддерживают SSD”
Kidd сказал, что NetApp будет использовать SSD с нативным интерфейсом SAS.

Объявлена новая стратегия NetApp в области Cloud Systems.
Анонсирован выход в сентябре Data ONTAP 8, продукта объединяющего “классическую” 7G и ONTAP GX.

Ну и по мелочи: новая дисковая полка DS4243 - 24 диска SAS/SATA в корпусе 4U
PAM II - новая модель в линейке Performance Acceleration Module - 256GB flash-памяти (up to 4TB) (в PAM I была только RAM 16GB)
В начале 2010, с выходом 7.3.3, появится функция NetApp Data Motion - средство nondisruptive и прозрачного для приложений перемещения данных между системами NetApp и tier-ами хранения, например между SAS/FC и SATA-разделами.

Мой любимый нетапповский автор, Костадис Руcсос, который в своем блоге на днях закончил длиииинную десятичастную тему, тоже говорил, что в принципе это bad taste in blogging, устраивать такие “сериалы”, так как внимание даже искушенного и лояльного читателя теряется. Надо как-то стараться писать коротко и ясно. Вот всякий раз, как я начинаю в блоге травить анекдоты, сразу налетает толпа, так, на недавний пост с “автопроизводителями”, за три дня пришло почти треть обычной месячной аудитории блога. А то я все умничаю. Во, народу надо доступных зрелищ, это еще древние римляне понимали. ;)

Поэтому пост будет недлинный, нетрудный, и с картинками :)

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

Давайте рассмотрим это на примере небольшой и относительно недорогой, а потому особенно популярной в России системы начального уровня FAS2050.

Это система уровня low-enterprise, вторая с “нижнего конца” (младше ее есть еще FAS2020, предназначенная для совсем небольших инсталляций и систем).

Она представляет собой конструктив  высотой 4U, на 20 дисков 3.5”, вставляемых горизонтально “с лица”, и двумя контроллерами (часто мы называем их на жаргоне “головы” или “filer head”), обеспечивающими отказоустойчивую работу в режиме active-active cluster.

Каждая “голова” несет на себе (слева-направо):

• 2 порта 4GB FC, которые могут использоваться как FC-target (по простому – к ним можно подключить сервера SAN-сети, и они смогут использовать LUN-ы на NetApp), а также к ним можно подключать дополнительные дисковые “полки” расширения. Дисковые “полки” едины для всех моделей NetApp, могут нести в себе по 14 дисков SATA или FC (каждый тип полки под свои диски), и подключаются к контроллерам по интерфейсу FC (даже если диски в них SATA).
• Разъем последовательного порта для непосредственного консольного доступа (аналогичен такому же порту например на оборудовании Cisco, и некоторых других устройств), использует разъем RJ-45, и выглядит как сетевой, но не перепутайте.
• Порт сетевого подключения к BMC – Baseboard Management Control, отдельной управляющей подсистеме, с помощью которой можно организовать отдельную “подсеть” управления, если вы, например по соображениям безопасности, не хотите управлять системой из обычной “общей” LAN. Кроме этого, через BMC можно управлять системой на том уровне, когда обычные сетевые контроллеры еще не работают, например при загрузке системы и Mantenance Mode.
• Два независимых порта Gigabit Ethernet. Каждый из этих портов может работать независимо, например можно создать две подсети доступа, или по одному из интерфейсов подключаться как к NAS, по протоколам NFS или CIFS, а ко второму – по iSCSI. Можно также объединить эти порты либо в отказоустойчивую схему, либо в транк, при котором скорость передачи данных удваивается.
• Выше ряда разъемов интерфейсов располагается заглушка слота PCIe, в которую могут быть установлены платы расширения NetApp, такие как: дополнительные порты FC, Ethernet, аппаратный iSCSI HBA, и даже UW-SCSI, с помощью которой можно подключить к FAS ленточный накопитель, и делать автономный бэкап его содержимого на ленту.

Контроллеры или “головы” полностью автономны, и могут работать независимо, каждая со своим набором дисков. В случае выхода из строя одной из них, или отказа, например, доступа по сети к какому-то из них, система переводит диски такого контроллера, а также все ресурсы (имена файловых шар, IP-адреса для NAS, WWN-ы для SAN) на “выживший” контроллер, и, с точки зрения пользователя, работа в случае такого “cluster takeover” продолжается “прозрачно”, без необходимости ручной перенастройки на серверах и клиентах (хотя, конечно, производительность и падает, ведь теперь один контроллер работает “за двоих”).

Устанавливаемые в базовый конструктив диски могут быть либо SAS, либо SATA. Системы семейства FAS2000 впервые начали использовать диски SAS, так как ранее системы FAS использовали диски FibreChannel (FC). ??спользование дисков с интерфейсом SAS позволило несколько снизить стоимость системы, однако не в ущерб надежности. Опубликованные данные говорят о том, что применяемые диски SAS и такие же FC отличаются лишь контроллером и типом интерфейсного разъема. Надежность и быстродействие их идентичны.

Такая система продается в двух вариантах “набивки”, на 12 дисков, и на 20 дисков.

Предположим, вы выбрали конфигурацию на 12 дисков. К примеру, вы выбрали диски SAS 450GB 15K, и посчитали, что 12 дисков дадут вам 5.4TB пространства, чего вам замечательно как раз на все и хватит, и при этом не обратили внимание на предупреждения продававшего вам систему специалиста NetApp или его партнера.

“Неприятности” начнутся на этапе первоначальной установки.

Так как наша система кластерная, и имеет два независимых контроллера, нам надо разделить диски между контроллерами. Если мы делим их поровну, то каждому контроллеру достается по 6 дисков.

Теперь на этих 6 дисках мы создаем RAID-ы. Допустим мы выбираем тип RAID по умолчанию, так называемый RAID-DP, нетапповский вариант RAID-6, но без потерь производительности и быстродействия, характерных для “обычного” RAID-6. В случае дисков SATA это, на сегодня, единственно приемлемый тип, но и в случае SAS это вполне разумный выбор.

При создании aggregate и RAID из наших 6 дисков вычтется один (в случае RAID-4) или два (в случае RAID-DP) диска на хранение parity. Кроме этого, каждому контроллеру надо выдать один диск hot spare.

??того, мы получаем из 12 дисков два RAID по 3 usable диска в каждом. То есть, в случае выбора дисков SAS 450GB: 3×450GB = 1350GB на каждом из контроллеров. Обратите внимание, объединить их, например, чтобы записать на них 2.7TB “одним куском” не получится, только двумя кусками по 1.35TB.

На рисунке коричневым показаны диски parity для контроллеров A и B, зеленым – hot spare, и синим – диски данных. Обведен красным диски контроллера А, синим – контроллера B.

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

Тем не менее “Ну ужас, да. Но не “ужас-ужас”, как говорила героиня известного анекдота.

Говоря начистоту, никто из наши конкурентов не рассматривает иные типы RAID кроме RAID-10 в качестве основы для хранения primary data, то есть активных рабочих данных, будь то базы данных SQL, почтовая база Exchange или хранилища виртуальных машин.

Поэтому, гипотетический простой стиральный порошок сторадж на 12 дисков, какой-нибудь другой компании, при выборе RAID-10, даст ровно тот же результат в 50% usable от общего объема. При этом, прошу отметить, RAID-DP объективно надежнее, практически такой же быстрый, и мы получаем с ним еще и два hotspare диска.

Но самое интересное получается дальше.

Если мы захотим теперь расширить емкость нашего FAS2050, добив его дополнительными 8 дисками до 20 штук в базовом конструктиве, то мы сможем все эти диски добавить как диски данных.

В то время как в “обычном сторадже”с RAID-10, в usable будут снова только половина.

Как видите, с увеличением количества дисков в системе, эффективность использования пространства дисков у NetApp возрастает.

Но это не предел.

Максимальный размер одного RAID для дисков SAS и FC в системах хранения NetApp допускается до 28 дисков*. Рекомендуемая величина (делать “очень длинный RAID” по разным причинам не самая лучшая идея) – 16 дисков.   
 

Если мы добавим дисковую “полку” расширения к нашей системе, мы сможем довести соотношение usable к raw до 82%! ??з 34 купленных дисков, мы можем отдать под данные целых 28! При этом не поступившись ни надежностью, ни быстродействием. 
Результат более чем впечатляющий. 

Выводы очевидны.

• Чем больше дисков в системе у NetApp, тем выше эффективность их использования.
• ”Побочный” расход дисков на системах NetApp довольно велик для систем с небольшим количеством дисков, но почти не увеличивается при дальнейшем их добавлении.
• ??збегайте покупать системы NetApp с дисками “впритык” (особенно небольшие), обязательно при покупке уточните вопрос, сколько в результате получится usable space, чтобы избежать неприятных сюрпризов на этапе пусконаладки.

–
* Один aggregate (и тома на нем) могут располагаться поверх множества независимых RAID-групп (16+16+16…). В пределах заданного при создании aggregate размера RAID, диски добавляются в него, по достижению заданного размера (например 16 дисков) начинается новый. Текущий лимит на размер aggregate/тома для всех систем под ONTAP 7G (кроме 2020) - 16TB

NetApp и Cisco давно связывают многие и просто хорошие отношения, и бизнес-инициативы. Недавно был опубликован очередной отчет в success stories.

http://media.netapp.com/documents/cisco.pdf

Cisco перевела свыше петабайта своих стораджей под БД Oracle на 4 штуки NetApp FAS6070C по FC и NFS, и за 8 месяцев сэкономила в терминах TCO около 8 миллионов долларов на электропитании и стоимости хранения, и в ближайшее время ожидается еще около 10 миллионов экономии при развертывани новых баз.

67 инстансов (backend Oracle 9.2, 10.2 и frontend 11i), размером некоторых до 30TB, на 22 серверах HP-UX, с применением thin provisioning и дедупликации удалось сократить в объемах storage footprint на 67 процентов.

Предыдущие посты серии:

Первый
Второй
Третий
Четвертый

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

На каждом томе можно создать 254 снэпшота. С учетом максимального количества томов, возможных на системе, получается суммарно около 51 тысячи. Впрочем это скорее теоретическая величина, поэтому заостряться на ней не будем, что же касается снэпшотов то вам их, я полагаю, хватит в любом случае. Напомню, что решения, называющие себя “снэпшот”, у конкурентов обычно заметно ограничивают их количество в 14-30 на всю систему в целом (см. комментарии). Такое ограничение вызвано не в последнюю очередь тем, что использование snapshots у таких систем резко влияет на производительность, и, обычно, снэпшоты на них массово просто не применяются, так как весьма значительно “сажают” производительность системы в целом.

Раз мы добрались до тома и его снэпшотов, позвольте подробнее остановиться на непростой, и вызывающей множество непонимания теме “резервирования” или snapshot reserve.

Когда-то, давным давно, когда NetApp был только NAS системой, было эмпирическим путем определено количество места, которые отводятся и резервируются под снэпшоты, в 20% от общего объема тома. То есть, для простоты понимания на конкретном примере: из тома в 100MB на блоки, зафиксированные в снэпшоте, мы отводим 20MB (на основные данные остается, соответственно, 80MB).

Для правильного понимания того, как работает резервирование, стоит нарисовать вот такой рисунок:

В ней, для простоты изображения и понимания, данные, записываемые на том, прирастают снизу.

Блоки, попавшие в снэпшоты, прирастают сверху.

Граница “резерва под снэпшоты” это линия, отделяющая верхние 20% емкости, в которых прирастают (условно сверху вниз) данные снэпшотов.
При этом, граница эта “проходима” сверху вниз, но не снизу вверх. То есть, если случилось так, что снэпшотов создалось больше, чем на 20% резерва, например на 25, то будет заняты “сверху” 20, и плюс еще кусочек на 5% “сверху” от активного тома.

Однако, когда мы попытаемся записать активных данных больше 80MB на 100MB-том с резервом в 20%, даже если это резерв и не используется снэпшотами, мы получим сообщение о нехватке места. То же самое произойдет и если двигающиеся “навстречу” данные “активной файловой системы” и снэпшотов встретятся.

Перед этим система будет сыпать алертами о исчерпании места, например в уже рассмотренном случае, когда снэпшоты “вылезли” из пространства резерва, в сообщении будет говориться о “заполненности тома на 105%”. Проценты свыше 100 это как раз то, насколько из резерва вылез хвост объема снэпшотов.

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

Можно ли изменять величину снэпрезерва? Разумеется да.
Можно ли поставить ее в 0%? Да.
Отключит ли это возможность создавать снэпшоты на томе? Нет, просто снэпшоты сразу будут занимать место в пространстве “активной файловой системы” тома. Представьте, что граница с рисунка поднята до упора вверх, но она по прежнему проходима для снэпшота, растущего сверху вниз.
Чем это грозит? Да по сути ничем, просто вам надо будет либо не пользоваться снэпшотами (опрометчивый, но имеющий право на существование способ использования стораджа NetApp), либо внимательно контролировать заполнение тома и величину пространства, занятую снэпшотами, чтобы они случайно не исчерпали собой доступное для данных место.
Зачем вообще нужно это резервирование? Ну это просто удобно. Сисадмин системы хранения знает, что у него всегда есть специальный запас места для создания снэпшотов, что туда никто кроме них не залезет и не займет, и снэпшоты, пока это место не переполнится, всегда на томе будет где создать. То есть это просто такое средство немного облегчить жизнь и снизить количество мест, которые надо контролировать.

Традиционно решение ставить snapreserve в 0% применяется при использовании системы NetApp в качестве чистого SAN, когда на volume создается LUN, равный ему по размерам, а создание снэпшотов не используется, и не планируется.
Однако чаще для такой конфигурации, в особенности когда планируется _использовать_ снэпшоты, рекомендуется устанавливать резервирование в 100%. Тогда, даже в самом наихудшем случае, когда все блоки LUN-а изменены, то места на снэпшот хватит.

Я уже писал подробно про этот вопрос в посте про использование “Fractional Reserve”.
Там же я рассказывал про другой способ решения проблемы снэпшота для тома с LUN - автоматическое увеличение тома, опция “autogrow”, в том случае если на aggregate, где он расположен, есть свободное пространство.
Вы можете не резервировать место при создании тома, а просто в свойствах тома сказать, что, когда понадобится, он может расти, занимая под себя свободное место в aggregate.

??так, мы создали том, и задали ему snapshot reservation ту, какую захотели, например 20, или 15% в случае планов использования данного тома под хранение файлов (NAS), 0 или 100%, или определили fractional reserve, опции autogrow и autodelete, при использовании его для размещения на нем LUN-а.

…и почти добрались до конца. Теперь давайте посмотрим, что же у нас получилось с usable.
Окончание (надеюсь) в следующий понедельник (надеюсь).

Наконец то дошел до публикации мой перевод Руководства по наилучшим методам использования и настройки систем хранения NetApp для виртуальных инфраструктур VMware VI версии 3.
Это совместная работа специалистов NetApp и VMware, поможет использующим VMware с этими СХД, впрочем в работе рассматривается много вопросов и “аппаратно-независимых”, которые будут полезны при использовании и не только NetApp, например организацию и настройку многопутевых подключений ethernet-системы хранения (iSCSI, NFS) к серверам фермы VMware VI с помощью транкинга.

Шел он к публикации долго. Настолько долго, что за это время уже успел выйти следующий документ, по работе с VSphere (VI 4). Но тут уж не моя вина. Пока не ясно, будем ли мы готовить новый перевод, но если - обязательно сообщу.

По крайней мере, как я знаю, это единственная такая инициатива на русском языке среди производителей систем хранения.

Читать тут:
http://www.netwell.ru/production/techbiblioteka.php

Традиционное “четверговое” несерьезное. Перевод. Ссылка на автора в конце.

Если бы вендоры систем хранения были бы производителями автомобилей, то кто был бы кем?..

EMC это Mercedes-Benz
Большие. Дорогие. Мощные. Многие говорят, что они - лучшие, но кое-кто поговаривает, что король-то одет как-то… не очень. Так или иначе, но вы хотите это купить. Но что случилось со всеми этими странными моделями и брендами? Даже модели нижнего уровня стоят вдвое против обычной цены у других, и так трудно сбить ее, даже когда так много конкурентов ходят вокруг… Некоторые думали, что покупка компании из нижнего и массового сегмента (Iomega) “понизит” бренд, но на деле это приводит к странной синергии, которую мы только начинаем видеть, не говоря уж о понимать.

HDS это Toyota/Lexus
Топовые модели “кусаются” ценником, но все же не так, как у “больших парней”. В нижнем сегменте - вкусные штучки, но уже не по той цене, как было когда-то. Они эффективны, мощны и богато выглядят, предлагая все что вам необходимо, и даже то, чего нет ни у кого. Но во всем этом нет изюминки. Неважно насколько они хороши, или сколько стоят, у всех возникает подлое чувство, что вы продешевили, или схватили первое же, что вам дали на тест-драйв.

IBM это General Motors
Они когда-то правили всем рынком, и задавали стандарты всему миру. Они изобрели или популяризовали кажется все что есть в отрасли, имеют огромную долю рынка, и огромный оборот. После нескольких спотыканий и падений, вернулись с отличными продуктами и, кажется, настоящими инновациями. Но, кажется, люди просто не хотят больше давать им в кредит. Ну и пусть они продают как сумасшедшие, но куда-то ушел гламур. Время перестройки, и никто не знает, чем она окончится: будут они править миром вновь, или загнутся окончательно?

HP это Ford
Еще одна компания, думающая что она изобрела все на свете, но инсайдеры-то знают, кто сделал это на самом деле. Конечно, он не правят рынком нынче, но несколько раз этим занимались раньше. Некоторые из их лучших технологий были куплены на стороне, но кто говорит, что это плохо? Соберем все вместе, и это будет настоящая сила на рынке, которая захватит его, пока остальные отвернулись.

Sun это Chrysler
Ни у кого нет такого количества фэнов, как у них. Конечно, они никогда не правили миром, но вот уже десятилетие за десятилетием выкатывают все новые и новые клевые продукты. Все уже сбросили их со счетов, но они всегда возвращаются с чем-нибудь интересным. ?? тогда реалии бизнеса сбивают их с ног. Будет еще один выход на сцену, или на этот раз уже все?

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

NetApp это Honda
Они уже не такие недорогие, как были когда-то, но они показывают, что вы можете сделать многое без излишнего расширения (over-extending yourself). Они упорно отказываются делать что-то также как делают все, и продолжают добавлять штучки и усовершенствования до тех пор, пока не становятся реальными конкурентами даже для “больших парней”. Если вы спросите их об этом откровенно, они укажут на эту компанию, как на главную для себя угрозу.

3PAR это BMW
Спросите любого владельца, и вы услышите оду, о том, какие они замечательные. Конечно, они дорогие, но также хороши, как лидеры рынка, если не лучше! Они по прежнему небольшая компания, пытающаяся выжать максимум из небольшого набора базовых узлов. Все впечатлены, что они остаются самостоятельными и независимыми так долго, и аналитики продолжают предсказывать, что их скоро купят!

BlueArc это Jaguar
У них есть только несколько моделей, и они предлагают убойную производительность за немалые деньги. Некоторые их клиенты никогда не приобретут больше ничего другого, но остальной мир скребет в затылке и гадает, кто их купит в следуюший раз и когда.

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

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

Xiotech это Nissan
Даже их клиенты в целом не слишком впечатлены, но все согласны, что они крепкие и надежные. Но они работают над некоторыми штуками, которые никому не показывают пока, и, может быть, это будет вторым дыханием!

Nexsan это Kia
Они дешевые и прочные, и держатся молодцом. Но пресса и аналитики всегда их игнорируют…

NEC это Mitsubishi
Вы забыли, что они что-то еще делали? Нет, правда, хорошо продаются, и некторые на самом деле их любят. Правда, вам надо взглянуть. Эй, погодите, не уходите!

Texas Memory Systems это Lotus
Вы скорее всего столкнетесь с ними, работая с другим вендором, но они предлагают абсолютно крутейшую производительность, если у вас есть на нее деньги. Но как долго продержится такой крохотный нишевой производитель?

Violin это Spyker
Ктооо? Кто-нибудь видел это вживую вообще?

Взято тут: http://blog.fosketts.net/2009/08/07/storage-vendors-automakers/

Да уже и не must, а почти что almost.

Еще несколько слов аргументации за переход к RAID-6, тем, у кого он не тормозит, не будем показыват пальцем, но: “Есть такие вендоры!” ;).
Да, согласен, RAID-10 тоже вполне может пережить отказ двух дисков, если вам повезет, что это произойдет в разных половинах “зеркала”. Но только в этом случае.

—————
RAID 5 появился в 1987 году, и был вполне адекватен решаемым задачам на протяжении следующих 15 лет непрерывного роста. Обычный размер диска в 1987 был всего 21MB, да, именно МЕГАбайта, и скорость вращения была 3600 RPM. На протяжении следующих 20 лет, диски выросли до 1TB (в 50 тысяч раз больше, но только вдвое-вчетверо в скорости вращения). Этот огромный рост привел к проблеме и продемонстрировал ущербность данного уровня RAID.

Проблема заключается во времени, которое уходит на перестроение большого по объему RAID, которое может исчисляться днями. Это может привести вас к проблеме выхода из строя второго диска на том же RAID, в то время, как процесс ребилда еще не завершился. Величина под названием Annual Failure rate (AFR) для дисков становится лучше год от года, но это не устраняет проблему продолжающегося роста времени ребилда. Другая проблема состоит в том, что в процессе ребилда нагрузка на диски существенно возрастает, что, в свою очередь, увеличивает вероятность отказа, так что процесс ребилда сам по себе может быть для дисков еще опаснее*1 (до 2.5 раз).

Допустим, AFR (Annual Failure Rate, “вероятность отказа”) равен 5%*2, и время ребилда равно 1 дню. Мы используем 9-дисковый RAID-5 (8+1). Шансы получить второй дисковый отказ за это время равен 1/365 x 5% x 8 x 2.5= 0.25%. Допустим, у нас используется 100 таких групп по 9 дисков в RAID 5 в системе (900 дисков). Я могу ожидать, что получу 45 отказавших дисков в течении года. Во время прохождения ребилда я “бросаю кости”. У меня есть 1 шанс из 400 получить за время ребилда отказ второго диска, приводящий к потере данных, и я “бросаю” эти кости 45 раз в год. В течении 5 лет срока службы это означает вероятность 225 из 400 получить катастрофический сбой с потерей данных.

Давайте рассмотрим теперь тот же сценарий, но удвоим размер дисков, и понизим AFR (Annual Failure Rate, “вероятность отказа”) с 5% до 4% (имитировав развитие рынка HDD и выход новых боле емких моделей дисков). Теперь у нас уходит два дня на ребилд, так как удвоился объем, и формула выглядит так: 2/365 x 4% x 8 x 2.5= 0.4%. Те же 100 RAID-групп, те же цифры предположений, но риск двойной ошибки вырос до 1 к 200, хотя я “бросаю кости” только 36 раз в год. На протяжении пятилетнего срока службы это означает шанс 180 из 200 получить катастрофический отказ.

Это выглядит противоречащим здравому смыслу, но тем не менее это так. Да, диски становятся надежнее, но при этом, тем не менее, риск аварии возрастает.

Примечания:
*1: http://www.snia.org/education/tutorials/2007/fall/storage/WillisWhittington_Deltas_by_Design.pdf, см. слайд 50
*2: Официально опубликованный вендорский AFR для дисков всегда ниже 1%Однако множество источников называют размер этой величины вплоть до 12%, Можно считать, что величина “консенсуса” в данном вопросе находится обычно между 3% и 5%.
————-
Найдено и переведено там:
http://blogs.netapp.com/msenviro/2009/08/the-raid-10-upsell-fudbeast.html

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

То для сравнения возьмут какую-нибудь позапрошлую модель конкурентов и сравнят ее со своей текущей, то понастраивают на чужом сторадже что-нибудь этакое, что хоть падай.
По этой причине я всегда с настороженностью и применением поговорки “Doverjai, no proverjai” отношусть к такм данным. ?? уж точно почти всегда воздерживаюсь от откровенного “говнения” конкурентов. Зачем? Во первых я убежден, что современные технологии достигли таких высот, что в, наверное, 80 процентах случаев разница в enterprise-class системах практически нивелирована, разве вы только используете какие-то особеные, уникальные возможности конкретного оборудования, но у “мэйнстрима, в отличие от нетаппа, их, на деле, не столь много.
Во вторых, я считаю, что рынок России огромен, и на нем есть место для всех (и еще останется). Так что устраивать тут “собачий бой в грязи” на потеху покупающей публике, не даст нужного результата, кроме того, что все в ней изваляются :)

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

Ну так что же о флюсах?

Хороший пример всплыл недавно. С некоторых пор к традиционному “кусальщику NetApp-а” в лице Чака Холлиса (EMC) добавились “корпоративные блоггеры” HP. В стратегическом смысле это не может не радовать, “нападают - значит боятся”, впрочем давно пора, системы хранения NetApp уже не первый год стабильно и последовательно откусывают заметные куски у рынка “Настоящего FibreChannel”, чтобы это можо было продолжать публично не замечать.
Но вот уровень компетентности при этом демонстрируемый заствил меня написать этот пост из разряда: “Посмотри, и никогда так не делай”.

В посте блоггер HP предьявляет, по его мнению, убийственные вопросы, на которые NetApp будет вынужден ответить “да”, и вслед за этим, рыдая, на коленях, рвя волосы ползти вслед за кастомерами, и молить их о снисхождении за многолетний обман, раскрытый доблестными и бескорыстными рыцарями из HP.

Вопросы выглядели так, будто, например, какой-нибудь американец 40-х из какого-нибудь штата Алабама, спрашивал бы какого-нибудь современного руководителя: “А что, правда говорят, я конечно не верю, но все же… что у вас… (понизив голос) в компании работают ЧЕРНЫЕ? ?? что они, хе-хе, даже в одних комнатах с некоторыми белыми сидят?” - “Ну да” - отвечают ему недоуменно, “да, отчего бы нет, работают и сидят”. “Слышите! Слышите!” - взвивается тот - “Он сам, сам признался! У них - ЧЕРНЫЕ! Все в одной комнате! Какой позор! Никто его не заставлял, видели?! Сам сознался!”, и никак не может понять равнодушного недоумения, которое встречает его активность.

По видимому для нашего блогера HP ожидаемый ответ “Да” на вопросы:

Do you build your LUNs on top of a file system?
Does your file system write only to free block space rather than updating the old blocks?
Do you ship a de-fragmentation tool on every NetApp filer?
Do you use software RAID?

и так далее, “убивает” конурента на корню. ?? он никак не может понять (см. комменты) за что же над ним потешается Алекс Макдоналд из NetApp.