about NetApp

Продолжим внимательное чтение отчета специалистов Google - Failure Trends in a Large Disk Drive Population (pdf 242 KB) опубликованный на конференции FAST07, и содержащий статистический анализ отказов "популяции" 100000 дисков consumer-серий примерно за пять лет срока их службы.

Это четвертая, заключительная статья, предыдущие:
Насколько можно доверять величине MTBF?
Приводит ли большая нагрузка к повышению вероятности отказа?
Насколько полезен и стоит доверия SMART?

Мы обнаружили, что основной параметр отказоустойчивости, приводимый производителями, MTBF - Mean Time Before Failure, бесполезен, и не коррелирует вообще с реальными показателями отказов. Мы узнали, что SMART бесполезен едва ли не более, чем полезен, и что значительная часть отказов происходит без корреляции с показаниями SMART. Наконец, мы с неожиданностью поняли, что общепринятая "аксиома" о том, что высокая нагрузка повышает вероятность выхода из строя дисков - как правило, неверна.

Но главный сюрприз у нас еще впереди.

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

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

Как мы видим, повышение рабочей температуры до 40 градусов включительно приводит к снижению уровня отказов, но даже дальнейшее повышение ее до 50 и более поднимает его незначительно (отказы при температуре 50 градусов примерно соответствуют уровню отказов при температуре 30 градусов). Напротив, дальнейшее понижение температуры до 20 и менее, ведет к почти десятикратному росту отказов, относительно оптимальной температуры в 35-40 градусов!
(Большой статистический разброс результатов, показанный T-образными отметками, вызван снижением общего количества “испытуемых” дисков в предельных температурных областях)

Следующий график показывает величины отказов в зависимости от температур для разных "возрастных групп" (речь, конечно не идет о "трех годах работы" при определенной заданной температуре, так как наблюдение проводилось, как уже было сказано, в течение 9 месяцев) Результаты также подтверждают вышеприведенное наблюдение, расширяя его по "координате возраста".

"Переохлаждение" для дисков, то есть работа при температурах ниже 30 градусов (имеется ввиду, конечно же, температура самого диска как устройства, как ее определяет встроенный температурный датчик SMART), для устройств сроком до двух лет эксплуатации включительно, в два-три раза повышает величину отказов, даже по сравнению с ранее считавшимися "перегревом" температурами выше 45! Только для дисков старше 3 лет перегрев становится причиной повышенного выхода из строя. Снова видно, что для дисков, переживших 3 года, вероятность отказа сильно падает. Видимо где-то в районе трех лет проходит какая-то довольно заметная граница работоспособности.

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

Результат, по-видимому, еще стоит осмысления и оценки.

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

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

“Специалист подобен флюсу - полнота его односторонняя” сказал классик.
Одной из распространеннейших проблем 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.

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

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

Выслушал ЛПР всех трех и решил, видать, что опричники его неправильно тендер проводят, потенциального победителя зарезали почем зря и повелел вернуть компанию А в тендер. Долго ли - коротко ли, а повстречался он с компанией А несколько раз (не встречаясь более ни с кем из финалистов), выторговал с нее скидку и получил заверения, что как раз для него компания А обернется ясным соколом и будет соответствовать техусловиям, которым ну никак не соответствует сейчас и сделал свой не подлежащий обсуждению выбор.”

Так то :) А что, вполне реальная история. Не слишком усердствуй, когда хвалишь выбывшего из тендера конкурента.

Взято тут:
http://blog.chirkov.net/2009/06/14/sravnenie-sebya-s-konkurentami/

Ну раз у меня в эту неделю большой писательский кризис (на самом деле я готовлю новый перевод Best Practices, на это раз про MS Exchange 2007), то позвольте небольшой оффтопик.
Подслушанное в подкасте Stack Overflow Джоэла Спольски:

“Как кастрировать быка” это книга Дейва Хитца, основателя NetApp… это книга, в которой он рассказывает историю создания компании NetApp.

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

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

В дополнение к прошлым постам про “Большие игры больших мальчиков”

Facebook и Oracle

На днях также обнаружил, что такой популярный сервис хранения фотографий как Flickr (я и сам им пользуюсь), также хранит свои данные на системах хранения NetApp.
Что, в общем неудивительно, так как Flickr вот уже несколько лет входит в Yahoo!, а Яху, как известно, крупнейший в мире (по объемам хранения) клиент NetApp.
?? даже более того, после ухода Джерри Янга с поста CEO, его заняла Кэрол Берц, в прошлом также один из руководителей NetApp.

??нтересная статья о архитектуре Flickr была найдена на сайте highscalability.com, кстати и вообще это любопытное место, если вы интересуетесь принципами построения высоконагруженных решений.

По состоянию на конец 2007 года:

• Более четырех миллиардов запросов в день
• Примерно 35 миллионов фотографий в дисковом кэше Squid
• Около двух миллионов фотографий в оперативной памяти Squid
• Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
• 38 тысяч запросов к memcached (12 миллионов объектов) в секунду
• 2 петабайта дискового пространства
• Более 400000 фотографий добавляются ежедневно

Оригинал статьи.
Ее русский перевод.

К сожалению, никаких подробностей о том, что именно используется, пока не обнаружено. “Сервера хранения NetApp”. Ну и правильно, включили - работает, чего обсуждать. “сало як сало” ;) Как это похоже на NetApp…

Пример по настоящему большой системы, использующей NFS для VMware:

Около 1000 виртуальных машин, на 35 ESX-серверах, в двух локациях. Все на NFS нескольких NetApp FAS. С августа 2006 года отказались от FC SAN и перешли на NFS.

Система, созданная и работающая в крупной международной инвестиционной компании Invesco, получила 2007 NetApp Innovation Awards в категории Enterprise Infrastructure - награду, ежегодно присуждаемую за наиболее значимое внедрение технологий и решений NetApp.

“Я всерьез уверен, что даже сам NetApp не видел своего потенциала в этой области, пока мы не продемонстрировали значение снэпшотов и технологий репликации от NetApp в среде VMware” Dan Pancamo.

“В августе 2006 года, когда был анонсирован NFS для VMware, мы планировали крупное обновление нашей инфраструктуры VMware. На тот момент наша инфраструктура состояла из примерно 20 ESX-хостов, с, примерно, 750 виртуальными машинами, использующими по Fibre Channel систему хранения Hitachi. Мы также использовали много систем хранения NetApp, и, зная преимущества NFS перед SAN, мы решили исследовать возможность использовать системы NetApp по NFS с VMware. Я почти уверен, что мы были первыми клиентами NetApp, сделавшими это.

Конечно, первым барьером была производительность. К счастью, у нас были результаты производительности нашей VMware-системы, примерно за годичный период. После внимательного анализа этих данных, мы обнаружили, что уровень используемой полосы нашей SAN был весьма низок. В среднем он был в районе 10-15MB/s по всем 20 серверам, с пиками не превышающими 50MB/s. Так как миграция на NFS была проста, мы решили перенести несколько тестовых серверов на NFS. Все что мы сделали, это смотнитровали том NFS на ESX-сервер и запустили перенос виртуальных машин. После миграции примерно 100 VM на NFS в течении 6 месяцев, мы решили строить нашу новую инфраструктуру целиком на NFS.

Мы купили два выделенных специально под эту задачу NetApp 3070 и несколько новых восьмипроцессорных серверов, под ESX-хосты новых проектов. Мы также используем уже имеющийся у нас NetApp R200, хранящий снэпшоты за 21 день, для онлайн-бэкапов. Этот R200 также используется как запасная система, в случае полного выхода из строя основных хранилищ. В течении 6 месяцев мы полностью перенесли все наши виртуальные машины с SAN в NetApp NFS. Сегодня у нас примерно 1000 виртуальных машин в нашей системе VMware VI.

С нашей текущей загрузкой NetApp FAS3070 мы оцениваем возможности по расширению текущей системы по меньшей мере еще на 2000 виртуальных машин просто добавлением новых ESX-хостов. Нынешняя нагрузка по вводу-выводу на наш NetApp FAS3070C составляет в среднем 4MB/s с несколькими пиками до 30MB/s в течени дня. Никаких проблем с производительностью ввода-вывода не возникало. Наши администраторы VMware сказали, что все стало работать даже быстрее, чем в случае SAN, когда они устанавливают OS, при работе VMotion и клонировании.

Мы сейчас не запускаем в виртуальных машинах Exchange или SQL Server, однако с запланированным 10Gbit Eternet и Infiniband, как я думаю, скоро все реальные сервера перейдут в виртуальные.”