about NetApp

NetApp объявил о выпуске новой модели в линейке FAS2000, так называемых “low-enterprise class”.

Штучка получилась чрезвычайно любопытная.
Судите сами:

• Тот же конструктив (2U, на 12 дисков), что и FAS2020.
• Четыре онбордных Gigabit Ethernet порта на контроллер (8 на двухконтроллерную систему). Транкировать (в пределах котроллера) – можно.
• Онбордный SAS-порт (2 на двухголовую, соответственно), позволяющий подключать к ним новую SAS-полку DS4243 (24 диска).
• Два FC 4Gb/s остались.
• Поддержка Data ONTAP 8 (как в 7-Mode, так и в Cluster-mode (ex-GX!)).
• На 30% выше поддерживаемая емкость (136TB), чем у FAS2050 (при подключении полок расширения, конечно).
• Примерно вдвое выше производительность, чем у FAS2050 (по SPC-1 и SFS2008).
• Вдвое больше памяти и вдвое больше процессорных ядер (dualcore vs. singlecore) на контроллере.
• Максимальный размер aggregate – 30TB (на 64-bit aggregate под ONTAP 8.0), 200 томов FlexVol.

Цены… Хорошие цены, разумные, грамотные, спрашивайте у своего партнера. :) Кстати, что логично, изменились цены и на FAS2020/2050, если вас душила жаба – посмотрите, может уже можно договориться ;)

Слева направо: 2 порта FC 4Gb/s, порт SATA, system console (в RG-45), ACP (out-of-band management для SAS-полки DS4243), BMC (Baseoard Management Console), 4 порта Gigabit Ethernet.

Контроллер – взаимозаменяемый с FAS2020!
Что, вообще говоря, означает возможность апгрейда FAS2020 в 2040 простой заменой контроллера (не знаю насчет “на ходу”, но не исключено ;).

Новость слегка расстройственная для владельцев FAS2050, особенно в свете более низкой цены FAS2040, и значительно более высокой объявленной производительности. Ну что-ж, ждем FAS2070. :)
Зато на FAS2050 есть слот расширения PCIe, в который можно ставить расширения портов (2/4-port FC, 2-port GigE, iSCSI Target HBA, 2-port SAS (Disk extension) и UW-SCSI (Tape))

Кстати, немного не забыты и владельцы FAS2050. Теперь для 2050 есть 10Gbit-карта в слот расширения PCIe, которую, судя по всему, можно задействовать для FCoE.

С первого взгляда заметный минус 2020/2040 только отсутствие слота расширения, однако мощная “набивка” портами в “базе” решает большинство необходимых задач.

“Спрашивайте в магазинах города” :)

Продолжим внимательное чтение отчета специалистов 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, это явно не так.

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

Являющиеся частью стандарта ATA, средства мониторинга и предсказания ошибок, носящие название S.M.A.R.T - Self-Monitoring, Analysis and Reporting Tool присутствуют в контроллерах всех дисков ATA (как PATA, так и SATA) с 90-х годов. По мысли разработчиков этих средств, они должны предотвратить неожиданные выходы из строя, так как SMART оценивает ряд критичных параметров диска, и пытается предсказать вероятность таких сбоев, а также ожидаемое время до сбоя.

Группа исследователей Google на протяжении 9 месяцев анализировала данные S.M.A.R.T. в 100 тысячах дисков, расположенных в его датацентрах, выявляя взаимосвязи между отказами дисков, и показаниями этой службы. Было выявлено несколько критичных параметров, события которых чаще других вызывали впоследствии отказы таких дисков.

Scan Errors

Жесткий диск обычно постоянно проверяет чтение с поверхности физических дисков, и, в случае каких-либо затруднений в этом уведомляет S.M.A.R.T. В рассматриваемой популяции примерно 2% дисков на момент начала исследования имело ненулевые показатели Scan Errors, причем такие диски достаточно равномерно распределились между различными производителями и их моделями, то есть не шла речь о заведомо дефектных партиях. На графике ниже приведены показатели вероятности отказов для дисков, имевших ошибки Scan Error, и не имевших таких, по всем рассмотренным возрастным группам.

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

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

Вероятность отказа по всей наблюдаемой группе, после возникновения первого Scan Error. Пунктиром показаны границы статистически погрешностей.
Видно, что наибольший риск выхода из строя приходится на первые несколько дней после возникновения ошибки Scan Error.

Вероятность отказа после возникновения первого Scan Error, в зависимости от возраста диска.

В случае "нового" диска (с возрастом до 8 месяцев), если диск пережил первые несколько дней после регистрации Scan Error без сбоя, то вероятность его сбоя в дальнейшем относительно невелика и практически не возрастает. Однако чем "старше" диск на момент возникновения Scan Error, тем выше вероятность того, что на протяжении ближайших месяцев после Scan Error случится отказ. Для дисков возраста от года и старше, прирост такой вероятности за наблюдаемые 8 месяцев близок к линейному, что означает практическую неизбежность отказа, рано или поздно (к концу 8 месяца она дошла до 40%).

Вероятность отказа в зависимости от количества ошибок Scan Error. Рассмотрены варианты 1-2 ошибки и больше 2 зарегистрированных S.M.A.R.T. ошибок Scan Error. Множественные Scan Errors сильно увеличивают вероятность отказа, даже по сравнению с относительно высоким уровнем отказов после единичного Scan Error.

Таким образом, следует считать "пороговым" (threshold) значением для "scan error" - единицу. После первого же зарегистрированного scan error, вероятность отказа диска в следующие 60 дней становится выше в 39 раз!

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

В рассматриваемой популяции дисков ненулевое значение reallocation count имело примерно 9% дисков. Хотя некоторые диски имели значительно более высокие значения reallocation count чем другие, но, по утверждениям авторов, наблюдавшийся и описанный тренд был примерно равен для всех рассмотренных моделей и не зависел от производителя и марки дисков.

Также, как и в случае со scan error, рост этого параметра прямо связан с повышенной вероятностью отказа диска в самое ближайшее время. В среднем зарегистрированное повышение вероятности отказа составляло 3-6 раз. Эффект влияния этого параметра S.M.A.R.T. на вероятность выхода из строя хотя и был значительно менее выраженным, чем в случае scan error, но также явно фиксировался.

Графики роста уровней ежегодных отказов, в зависимости от возраста дисков, и наличия или отсутствия у них ошибок Reallocate.

Влияние reallocation на вероятность отказа в ближайшие 8 месяцев (пунктиром показаны статистические отклонения). По горизонтали - месяцы, прошедшие с момента регистрации reallocaion, по вертикали - вероятность отказа (survival probability - "вероятность выживания" - величина обратная вероятности отказа). Через 8 месяцев из популяции, имевшей хотя бы один reallocaton, остаются в строю примерно 85% дисков.

Влияние возраста диска в месяцах, на вероятность отказа после reallocation. В зависимости от общего возраста диска, меняется вероятность его отказа после возникновения reallocate.

Влияние единичных реаллокаций (от 1 до 4), множественных (выше 4) и сравнение с "контрольной группой". Множественные реаллокации, по сравнению с первой же обнаруженной, уже сравнительно мало влияют на вероятность отказа в целом, в отличие от ситуации с Scan Error.

В оригинальной работе также рассмотрены влияния на вероятность отказов таких параметров, как Offline Reallocation (вероятность отказа после такого события в 21 раз выше нормы в следующие 60 дней), Probational Counts (в 16 раз выше нормы, в следующие 60 дней) и ряда других.

Сводный график зарегистрированных S.M.A.R.T. событий в наблюдаемой группе. Суммарное количество превышает 100%, так как возможно возникновение нескольких ошибок одновременно.

Таким образом, очевидно, что, на сегодня, S.M.A.R.T., как средство Self-Monitoring, Analysis and Reporting, выполняет свою работу неудовлетворительно. Около трети сбоев (36%) в рассматриваемой дисковой популяции в 100 тысяч дисков не было никак диагностировано его средствами, и произошло внезапно для S.M.A.R.T. Анализ, проведенный группой инженеров Google, также выявил недостатки в текущей, общепринятой настройке "порогов" (threshold) срабатывания средств уведомления о предстоящей аварии, во многих случаях эти пороги следовало бы значительно поднять.

Бесспорны перспективы средств автоматического мониторинга и предсказания, встроенные в диски, однако, на сегодня, доверять безоглядно нынешним средствам, какими являются S.M.A.R.T. и системы, построенные на его базе, и строить оценку вероятности отказов жестких дисков исключительно на оценке S.M.A.R.T. не следует.

Продолжение следует.

Ранее: О надежности жестких дисков: MTBF – что это?

Приводит ли большая нагрузка к увеличению вероятности выхода дисков из строя?

В конце августа NetApp объявил о новинке в ряду своего оборудования – дисковой “полке” на 24 диска SAS. Эта полка – новый мэйнстрим, и в перспективе она планирует заменить собой все сегодня выпускаемые и используемые такого рода продукты: DS14MK2 (для дисков FC 2Gb/s), DS14MK4 (для дисков FC 4Gb/s) и DS14MK2-AT (для дисков SATA).

Продукт новый, необычный, и с перспективами, давайте смотреть подробнее.

Несколько слов о имени. Расшифровка такая: DS – Disk Shelf, дисковая полка, первая “4” – высота в 4U, “24” – 24 диска, “3” – ??нтефейс SAS 3Gbps.

Так как по мнению аналитиков SAS это новый лидер в enterprise-дисках, предназначенный сменить FC, то неудивителен интерес NetApp к этой области. Так, по мнению Gartner, выглядит прошлое (2007) и будущее (2012) рынка жестких дисков, а это уже совсем рядом.

Отсюда ясно, отчего NetApp проявляет большой интерес к SAS, ведь до сих пор его “мэйнстримом” были именно диски FC.

Первым опытом использования SAS в системах хранения NetApp приходится на 2007 год, когда были выпущены в свет модели FAS2020 и FAS2050, относящиеся к “low enterprise”, на которых использовались диски SAS и SATA в базовом “конструктиве”, корпусе на 12 и 20 дисков соответственно. Системы себя хорошо зарекомендовали и показали хорошие перспективы для SAS, так что новая дисковая полка это “второй выход”, уже на всем спектре выпускаемых систем, включая самые мощные FAS6000.

С набивкой дисками 1TB SATA: 24TB в размере 4U, и почти четверть петабайта raw data в стандартном 42U шкафу.

Вид дисковой полки сзади. Для варианта с дисками SAS нужна будет установка всех четырех блоков питания, для варианта с SATA – достаточно только пары.

В четыре имеющихся контроллерных слота на указанные месте ставятся новые контроллерные модули IOM3. Применение двух оставшихся слотов в настоящее время никак не описывается, и они остаются пустыми.

Контроллер IOM3 (Input-Output Module, 3GBps) это разработка NetApp, выполненная в соответствии с рекомендациями организации SBB – Storage Bridge Bay Working Group, создавшей спецификации на слот контроллера дисковой полки SAS. Потенциально любой SBB-контроллер может работать с SBB-совместимой полкой (хотя, на практике, конечно существует много способов сделать и так, что это работать не будет).  В этой рабочей группе в настоящее время состоят практически все значительные игроки рынка систем хранения, такие как EMC, Sun, NetApp, Intel, Xyratex, Infortrend, Adaptec, Emulex, Dell, LSI и другие.

На контроллерах IOM3 слева направо:
2 порта интерфейса ACP – Alternate Control Path. Это новая идея NetApp, специальный, out-of-band (независимый от канала передачи данных) порт управления контроллерами полок. Контроллеры всех полок в системе образуют по этим портам свою собственную IP-сеть управления, через которую “голова” системы может делать такие вещи, как считывать диагностику и осуществлять управление, считывать сообщения POST, а также заливать прошивку.

Данные дисков по этому каналу НЕ ПЕРЕДАЮТСЯ. Также наличие или отсутствие этого канала (обрыв, неисправность, неправильная настройка) никак не влияет на работоспособность системы и на возможность считывать и записывать данные на диски дисковой полки.

2 порта 3Gbps wide SAS. Наличие четырех портов SAS при стандартной установке двух контроллеров IOM3, позволяет организовать подключение типа Multipath High Availability (MPHA).

Более плотная дисковая “упаковка” в DS4243 позволяет получить на 30% больше емкости в том же физическом объеме (например в стойке на colocation в датацентре, per Unit).

Частый вопрос: Если раньше мы использовали 4Gbps FC, а сейчас мы получили 3Gbps SAS, означает ли это, что скорость стала на четверть меньше?
Ответ: НЕТ, не стала. На два контроллера мы имеем 4 порта так называемых “Wide SAS”  по 3Gbps, способные работать одновременно, то есть теоретическая, агрегированная полоса передачи данных с дисков достигает 12Gbps, то есть в три раза выше, чем в случае FC.
Тем не менее следует понимать, что в реальной жизни вы вряд ли увидите заметный прирост скорости по сравнению с полкой FC 4Gbps только по этой причине, как правило даже полоса в 4Gbps на современных дисковых полках используется далеко не полностью. Как я уже писал ранее, увеличение неиспользуемой части полосы пропускания не увеличивает реальное быстродействие системы. Но может быть, когда-нибудь…

Также в новой дисковой полке ниже энергопотребление “на TB” что также может пригодиться, в особенности для “больших систем”. Мы привыкли к тому, что затраты на “электричество” питания (как и “холода” кондиционеров, что взаимосвязано) считать как бы и не принято. Однако я уже приводил пример такой большой инфраструктуры хранения, как Facebook, который тратит только на электричество для питания своего оборудования в датацентрах миллион долларов в месяц. 10% экономии в этом случае могут вылиться в совсем невиртуальные деньги.

??так, для использования новой дисковой полки в новой или уже установленной системе вам понадобится карта интерфейса SAS (2-портовая для FAS2050, 4-портовая для всех остальных) в слот PCIe, ну и, конечно, сам свободный слот в контроллере.

Думаю, что новые модели контроллеров будут уже выпускаться с “набортными” портами SAS, как сейчас обстоит дело с портами FC.

На данный момент использование DS4243 не поддерживается в системах Metrocluster, что связано с ограничениями на максимальную длину соединения SAS – 5 метров. Возможно, после появления конвертера SAS-FC эта проблема будет также решена.

Также пока нет поддержки этих полок в системах VTL.

Дисковая полка будет поставляться в двух вариантах “набивки”: полная, на 24, и “половинка” – на 12 дисков. Смешивать SAS и SATA по прежнему будет нельзя, однако “полки SAS” и “полки SATA” теперь могут сосуществовать на одной системе гораздо более гибко. Все нынешние и будущие диски NetApp будут поддерживаться в новой полке.
Также обратите внимание, что конструктив дискового “фрейма” для DS4243 несовместим с дисковым фреймом FAS2020/2050, хотя диски при этом и те же самые, однако просто снять их и переставить в новую полку нельзя.

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

Мы считаем само собой разумеющимся тот факт, что бо’льшая нагрузка на диски вызывает их более ранний выход из строя. Так ли это? Данные Google показывают, что это не так. Более того, результаты сами по себе неожиданны.

На графике мы также видим уже знакомый нам период "детской смертности" в первые три месяца. Однако если мы разделим диски в зависимости от их рабочей нагрузки, то мы увидим неожиданное. Да, высокая нагрузка (выше 75%) в первые три месяца действительно приводит к высокой "смертности" дисков. В это период диски под высокой нагрузкой, по уровню AFR - Annual Failure Rate - среднегодовому показателю отказов, достигают 12% (при усредненной по всем типам нагрузок - в районе 3%). Однако, что неожиданно, диски с низким уровнем (ниже 25%) нагрузки также имеют довольно высокий уровень, около 4%, а наиболее низкие показатели в этот и 6-месячный период имеют диски со средними (от 25 до 75%) показателями нагрузки.

Переработка - плохо, но и простой - почти также нехорошо.

Далее же, в периоды 1 года, 2 и 3 лет, показатель уровня отказов практически не меняется от величины нагрузки на диски. ?? только после 4 года, и на пятый год, наблюдается заметное повышение уровня отказов для сильно нагруженных дисков, которое мы ожидали бы увидеть с самого начала. Таким образом, после первого полугода работы, уровень рабочей нагрузки на диски практически никак не сказывается (доли процента) на количестве их отказов. В ряде же случаев, наоборот, слабо загруженный диск имеет больше шансов вылететь, чем диск с рабочей нагрузкой среднего уровня. Диск, находящийся в Hot Spare вовсе не застрахован от внезапного выхода из строя.

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

Продолжение следует.

Начало: О надежности жестких дисков: MTBF – что это?

Давно, еще в 2007 году, я публиковал в одном из первых постов этого блога, ссылку на исследование группы инженеров Google, которое они обнародовали на одной из конференций исследовательской группы USENIX (USENIX File and Storage Technologies, 2007 - FAST07). На сегодняшний день это самое крупное такое исследование по количеству наблюдавшихся “в естественной среде” жестких дисков. Несмотря на то, что документ этот широко доступен, уверен, что мало кто сел и внимательно прочитал его целиком, а потом еще и подумал над содержимым. Потому что результаты там, подчас, предстают самые неожиданные.

??нженеры Google собрали статистику по отказам для примерно 100 тысяч дисков в своих датацентрах. Особо интересно нам, смертным, то, что Google использует у себя в серверах широкораспространенные consumer-series диски PATA и SATA (обеспечивая отказоустойчивость и надежность хранения инфраструктурно, за счет распределенной самописанной файловой системы хранения), то есть все те самые диски, которые окружаю нас повседневно, а не какие-то особенные, "энтерпрайзные". Документ, озаглавленный Failure Trends in a Large Disk Drive Population (pdf 242 KB) содержит статистический анализ примерно за пять лет их срока службы, при этом непосредственное наблюдение и снятие показателей заняло 9 месяцев. Несколько интересных, а подчас и неожиданных тем, обнаруженных при прочтении:

1. MTBF - Mean Time Between Failure - ожидаемый срок службы до сбоя. Что это?

MTBF - это традиционно приводимый производителям параметр, долженствующий, по их мнению, характеризовать надежность выпускаемых ими жестких дисков. Это искусственно вычисляемый срок в часах работы, которые ожидаемо должны проходить от одного отказа до другого, в случае соблюдения эксплуатационных норм (в том числе смены диска на новый, при окончании его гарантийного срока!). Эта величина, как очевидно, предполагает некую линейность в вероятности отказов. Так ли это на самом деле? Нет. Результаты Google показывают, что Annual Failure Rate, ежегодный процент отказов, для жестких дисков нелинеен в зависимости от их срока службы.

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

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

Тем не менее, 9% AFR означает то, что на системе хранения в сто дисков, купленной три года назад, после окончания трехлетнего гарантийного срока, вы скорее всего получите 8-9 мертвых дисков в течении следующего года. Дисков, которые придется менять уже не по вендорской гарантии, а за свои деньги.

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

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

Однако же про MTBF. Для consumer-series дисков периода 2002-2007 годов, обычно указывался MTBF равный 300.000 часов. 300.000 часов это 34 года непрерывной работы (300.000/24/365)! Если предположить, что MTBF имеет линейную природу, то это должно было бы означать AFR равный 1,46%, что, очевидно, не выполняется никогда, даже в лучшие периоды. Нетрудно посчитать, что, от партии в 100.000 штук, всего за пять лет, при приведенных в работе Google показателях отказов, останутся в живых только примерно 70% дисков.

Классический пример параметра "с потолка" и "ни о чем". Мы видим, что использовать его для реальной оценки надежности дисков нельзя.

Продолжение следует.

UPD: Еще одна интересную и содержательную статью о том, что же такое MTBF, как он вычисляется и как правильно его результаты трактовать “в жизни” смотрите тут:
http://habrahabr.ru/post/122529/

Приобретенный с компанией Onaro в 2008 году продукт управления и анализа инфраструктуры SAN (не только стораджей NetApp), выпускаемый ныне NetApp под названием SANscreen можно попробовать получить с вебсайта Onaro по следующей ссылке: http://gate.onaro.com/files/SANscreen-x86-5.1.1-248.msi

login: webuser passwrd: 1ceHockey! (1094MB)

Ранее, в посте про надежность RAID-5 я уже писал про такой аспект дисков SATA, как надежность и величину UER (Unrecoverable Error Rate, иногда также называется UBE - Unrecoverable Bit Error).
Величина эта почти на порядок (в 10 раз) хуже, чем для дисков SAS/FC, причем причина тут конструктивная, а не просто в интерфейсе.
Однако, для небольших систем “начинающих”, в первую очередь роль играет цена.

Жесткий диск (и система хранения) характеризуется, в общем случае, двумя параметрами: емкостью (измеряется в Мегабайтах/Гигабайтах (MB/GB)), и быстродействием (измеряется в IOPS - Input-Output Operations per Second - Операций ввода-вывода в секунду ). ?? если емкости дисков непрерывно растут вот уже несколько лет, то показатели по IOPS замерли уже довольно давно.
Принято считать, что диск SATA дает 80-100 IOPS, диски SAS/FC - 140-160 для 10KRPM, 180-200 - 15KRPM.

Стоимость за мегабайт для дисков SATA весьма низка, на сегодня она составляет 0,17$/MB для диска SATA 1TB, однако около 0.83$/MB для диска SAS 300GB. (я оперирую ценами, взятыми из price.ru: SATA WD RE3 1TB 7200 - 170$, SAS Hitachi 300GB 15K - 250$)

??ная картина будет, если мы посчитаем стоимость IOPS-ов. Диск SATA при этом будет стоить 2,1$ за IOPS, а 15K SAS - 1.38$/IOPS

Допустим, перед нами стоит задача создать сторадж на 3 TB, при этом быстродействие его должно быть не хуже 3000 IOPS.

Рассмотрим два варианта:
Если мы рассматриваем только емкость, то будет все просто:
SATA 1TB нужно три штуки, при цене за диск в 170$ общая сумма хранилища заданного размера, без учета RAID будет 510$
Дисков SAS на 15KRPM емкостью 300GB будет нужно 10 штук, при цене за диск 250$ такая емкость будет стоить 2500$

Казалось бы вывод очевиден, SATA дешевле, причем раз в пять.
Но мы пока не учли второе требование, про 3000 IOPS.

Для быстродействия системы емкостью 3TB в 3000 IOPS, из расчета в 80 IOPS с каждого диска SATA, нам нужно распараллелить ввод-вывод не менее чем на 38 дисков. 38 дисков SATA, это будет стоить уже 6460$.
Однако для дисков SAS те же 3000 IOPS достижимы на всего 17 дисках, что стоит 4250$

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

Этот момент часто не учитывают люди, планирующие использование SATA на задачах primary storage.

Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение - хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего, то вам следует забыть про гигабайты, и ориентироваться, в первую очередь, на производительность дисков, на IOPS. Необходимый объем вы получите “автоматичски”.
Сегодня, во многих случаях, при планировании системы хранения, производительность есть ее “первичное”, ключевое свойство .
??ли, иначе говоря: “GB are free, IOPS cost you money” - “Гигабайты бесплатно, вы платите только за доставку ??ОПСы”

Сегодня я бы хотел провести для вас своеобразный "мастер-класс говнилок", или, если угодно, "сеанс черной магии", разумеется "с последующим ее разоблачением". Я воспользуюсь для этого статьей небезызвестного блоггера Чака Холлиса, почти официального "говнильщика" компании EMC. В части "разоблачений" мне поможет Вэл Берковичи, блоггер NetApp, некоторое время назад сделавший показательный разбор одного из постов Чака.

Чак выбрал своей темой сравнительный анализ результатов получения Usable Space из Raw на трех разных платформах хранения - EMC Clariion, HP EVA и NetApp FAS. Ну за EVA, я надеюсь, вступится еще кто-нибудь, я же разберу двух оставшихся, тем более что я по EVA не спец, однако уверен, что и там вполне могут быть схожие "результаты".

Вэл очень показательно сравнивает манеры, при проведении такого сравнения с поведением фокусника. Сначала нам показывают нечто вполне обычное и привычное. Колоду карт. Кролика и шляпу. Женщину в ящике ;) Мы осматриваем их, и вынуждены согласиться, что да, никакого подвоха тут нет (обычно уже на этом этапе что-то не так, и хитрость уже спрятана, чтобы вовремя сработать).

На втором этапе фокусник превращает рассмотренные нами обычные предметы в что-то необычное. Что-то исчезает, что-то видоизменяется, и так далее. Вы потрясены.

Тут все зависит от того, хотите ли вы быть одураченными. Если да, как обстоит дело в большинстве случаев, вам ничего не остается как согласиться с фокусником: "Да все так, кролик исчезает в шляпе, а женщина перепилена", даже несмотря на то, что в глубине души вы и понимаете, что вас где-то провели. Но ведь вы внимательно следили!

В свое время, в каждом выпуске журнала “Юный Техник”, известный фокусник Эмиль Кио давал описания какого-нибудь незамысловатого фокуса (ну у него их много в запасе было), с объяснениями "как".

Попробую и я показать вам в каком месте у Чака начинается "ловкость рук".

??так, начало, The Pledge, "предъявление предметов".

Чак предлагает нам сравнить величины Usable Space на каком-нибудь простом и знакомом примере. Например инфраструктура хранения для MS Exchange.

Возьмем для примера шляпу диски FC 146GB, определим, что мы хотим получить на выходе пространство, равное емкости 120 дисков (около 17,5TB), и посчитаем, сколько дисков нам придется купить для системы, чтобы эти условия соблюсти.

Мы берем руководства Best Practices по установке для соответствующих систем, и начинаем, оперируя ими, рассчитывать пространство, "делать сайзинг" как это называется у нас.

Повторюсь, я не слишком большой спец в области конфигурирования EMC, поэтому я просто возьму анализ для CX4 самого Чака. Я не стану переписывать тут весь его пост, за подробностями можно пройти непосредственно к нему, покажу лишь сам принцип. ??так, перед нами стоит задача получить на выходе usable-емкость 120 дисков на 146GB. Что добавится к этой величине?

Диски hotspare - EMC рекомендует иметь 1 диск hot spare на каждые 30 дисков данных.

Пространство для snapshots - возьмем эту величину равной 10% от usable

Секторный оверхед - Clariion также как NetApp FAS использует увеличенный до 520 байт сектор, то есть примерно 1.5% к пространству usable.

Но что это? Внимательный взгляд уже видит первую ловкость. Отчего это Чак берет в качестве типа RAID для такой большой системы - RAID-5?

Даже если вас не убедила моя "дюжина ножей"(пост раз и пост два) в спину RAID-5, довольно будет и того, что это не рекомендует даже сам EMC в тех самых Best Practices, на которые сам же Чак Холлис и ссылается:

страница 15, документ #H4060, Oct. 2007:

It is generally accepted that RAID 1/0 is a better choice for random-write environments like Exchange

В том числе это так и для DMX (стр. 7-49):

http://www.emc.com/collateral/hardware/solution-overview/h4067-microsoft-exchange-server-symmetrix.pdf

As a matter of Best Practice, EMC generally recommends RAID1 to be the primary choice in RAID configuration for reasons of reliability and availability and performance for high-end deployments of Microsoft Exchange Server.

Вот он, трюк. Сейчас посмотрим, что получится в результате.

Кроме этого, Чак еще пару раз "забывает" о некоторых моментах, так, например, говоря о рекомендации делать right sizing на 10% для дисков в RAID на NetApp, для того, чтобы, при необходимости, можно было ввести в RAID диск слегка отличающийся по "геометрии", например спустя несколько лет, если поставляемые на замену диски отличаются от оригинальных в количестве секторов, он напрочь "забывает" это учесть в своем расчете для CX4, несмотря на то, что на это прямо указывается в Best Practices EMC.

Также не забудем и про пресловутый Vault на первых 5 дисках. Если в случае использования RAID-5 у нас были шансы использовать этот маленький пятидисковый RAID-5 в составе системы, также целиком выполненной в RAID-5, то в случае RAID-10 деть этот небольшой RAID-5 нам некуда, придется не использовать его для данной задачи вовсе.

??спользовать же эти 5 дисков в составе большого RAID-10 нельзя, так как Vault на них уменьшает их "аппаратную геометрию", и они становятся "несовместимыми" по размерам с остальными дисками системы. То есть минус 5 дисков целиком.

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

Что же у нас получилось?

А вот что:





Разительная разница по сравнению с цифрами, приведенными у Чака, не правда ли?

"Ловкость рук, и никакого мошенства".





 

Теперь займемся нашим NetApp FAS.

??сходные данные те же.

120 дисков по 146GB емкости в Usable, сколько должно быть в Raw?

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

Вот оно!

One thing is extremely clear — running out of snap reserve looks to be a very bad thing in a NetApp environment — there’s no place to put an incoming write, usually resulting in catastrophic application failure.  By comparison, other approaches (e.g. CX4 and EVA) simply stop trying to capture before-write data if you run out of reserve — the application itself continues to run.

…

It is recommended to have a 100% space reservation value set for volumes hosting LUNs containing Exchange data.

Разумеется в таком анализе не обойдется без традиционной спекуляции на тему 100% LUN space reservation. Как-то даже слишком предсказуемо.

Обязателен, неизбежен и абсолютно необходим ли 100% space reservation, как необходимо отдать 100% от объема data disks при создании RAID-10?

НЕТ.

Вы не можете уменьшить количество дисков, уходящих под "зеркало" в RAID-10, в котором Usable еще до всех "вычетов" всегда будет менее 50% от Raw.

Однако можете уменьшить количество места, отдаваемое под fractional LUN reservation в NetApp FAS, так как его уменьшение не ведет к неработоспособности.

Я уже останавливался ранее на том, что же скрывается за fractional (LUN space) reservation.

Скажу честно, тема непроста, но понять ее можно. Вот, если вкратце, на пальцах:

LUN space reservation это место, выделяемое и резервируемое на томе в том случае, если вы планируете использовать snapshot для LUN,и есть риск, что значительная часть объема этого LUN будет перезаписана. В этом случае резервирование пространства размером с весь LUN гарантирует нам то, что можно будет создать snapshot с этого LUN и место для нормальной работы с этим LUN-ом еще останется.

По умолчанию, руководствуясь правилом "прежде всего - не навреди" Data ONTAP действительно предлагает наиболее "консервативную" установку, в виде 100% reserve, гарантирующую, что даже если админ совсем ничего не понимает, и ставит систему Enter-ом, соглашаясь со всеми дефолтными настройками, то ничего смертельно опасного для его данных при работе не произойдет.

Означает ли это, что никаких других возможностей не предусматривается? Нет, не означает.

Можно ли не использовать 100% LUN space reservation, и чтобы при это все работало? Да, запросто.

Какие еще возможности есть? Можно, например, автоматически увеличивать размер тома, на котором расположен LUN, с тем, чтобы места хватало и на LUN, и на создаваемые Snapshots. А можно настроить автоматическое удаление старых снэпшотов, при создании более новых, если им не хватает места.

Ну и, наконец, если места не хватило, то предусмотрена возможность корректного автоматического размонтирования LUN-а, на котором невозможно продолжать запись.

?? все это - без необходимости резервировать 100% от usable space под LUN space reservation.

Давайте посчитаем по нашей методике raw space, взяв желаемый usable добавим к нему все "вычеты", "оверхеды" и "резервации", добавим диски parity RAID из расчета 2 диска на каждые 14 дисков (RAID-DP), и, наконец, hot spare (два на первые 100, и по два на каждые следующие 84), и посмотрим что получилось (все дробные величины округлялись в большую сторону до целочисленных значений, указанные на диаграмме значения показывают доли секторов диаграммы и не всегда равны процентам в таблице).





Для желающих поиграться - прикладываю мою табличку, где я все это рисовал.

EMC_vs._NetApp.xlsx

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

1. Представить себя как "независимое лицо", незаинтересованное в определенном "предвзятом" результате. Например проведите сравнение параллельно для нескольких вендоров.
2. Продемонстрировать все исходные материалы, упирая на их доступность.
3. Всегда аппелировать к вендорским Best Practices, пусть даже отдельные части их и будут проигнорированы, а сами они могут быть "outdated", устаревшими. Мало кто полезет проверять все подробности в 150-страничном PDF-е, в лучшем случае прочтет указываемое вами предложение в тексте, зачастую без контекстной связи.
4. Всегда сравнивать системы в выгодном для себя контексте. Ваша система имеет низкую производительность? Сравнивайте на задачах архивного хранения и резервного копирования. Система высокопроизводительна, но дорогостояща? Сконфигурируйте минимально возможную, пусть и неприменимую в реальной жизни конфигурацию. Малопроизводительна, но дешева? Активно пользуйтесь сравнением соотношения price/performance. Владея инициативой при написании документа - заставьте противника обороняться на неудобном для него поле.
5. Не забудьте о психологическом давлении и субъективности восприятия. Хорошее название для сравнительного документа "Вся правда о…". Почаще упоминайте "свободность" и "открытость" (“хорошо!”) в пику "проперитарности" и "закрытости" (“плохо!”).
6. Проводя в тексте нужный трюк, постарайтесь отвлечь от него внимание, например ссылками на какие-либо документы, или цитаты авторитетов. Актуальность их обычно не проверяется. Хорошо работают графики таблицы, иллюстрирующие ваши выводы, тем боле, что чаще всего перепроверять данные никто не полезет.
7. Отлично работают: “правильная” группировка результатов, а также маленькие хитрости, типа смешивания единиц измерения, неуказание единиц, нелинейная шкала отображения для графиков, и так далее.