Archive for the ‘review’ Category.

Тестирование производительности: инструменты

Тематика тестирования производительности и stress-test не отпускает, и поэтому я решил сделать небольшой обзор некоторых “подручных” (тех, которыми приходилось пользоваться) средств оценки и измерения производительности.

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

SIO

На вебсайте NOW, в разделе ToolChest найдена небольшая утилитка SIO – Simulated I/O, которая пусть  н столь совершенна и гибка как IOmeter, но тоже может использоваться с успехом. Она есть для Windows, Linux, Solaris, AIX и HP-UX, соотвтствующие версии можно скачать из ToolChest.

image

iozone

Исторически в Linux/UNIX средах популярна программка iozone. Она же существует и под другие платформы, в том числе и под win32. Текущая версия – 3.321 Программа имеет огромное количество ключей и настроек, в которых можно увязнуть надолго.  Описание всех их для всеобъемлющего тестирования далеко выходит за рамки этого поста, подскажу только, что с ключом –a (или –A, немного другой вариант) запускается некий дефолтный набор тестов “auto”. Также стандартный короткий тест запускается и при запуске iozone  без параметров, а ключи выводятся по –help.
В свое время в форуме sql.ru был составлен типовой паттерн тестирования, ориентированный на профиль баз данных, можно воспользоваться им.

iozone -i 0 -i 1 -i 2 -i 4 -i 5 -i 8 -e -o -c -s 4000M -r 4K -j 1 -f TEST4G4k.log -b /export/home/romx/testlog-4g4k.xls

iozone -i 0 -i 1 -i 2 -i 4 -i 5 -i 8 -e -o -c -s 4000M -r 64K -j 1 -f TEST4G64k.log -b /export/home/romx/testlog-4g64k.xls

Здесь, как видите, настроен тестовый файл размером 4000MB, и проводятся два тестирования, с блоком 4KB и 64KB, а результаты записываются в файл testlog-*.xls

SQLIO

Не отстает и Microsoft. На сайте MS можно скачать программку SQLIO, ориентированную, казалось бы, как явствует название, на симуляцию нагрузки MS SQL Server, однако в целом это утилита довольно широкого применения. Только под Win32. К программе прилагается файлик “Using SQLIO” - Using SQLIO to Stress Test an I/O Subsystem, с помощью которого можно во всем разобраться.

image 

SQLIOSim

Однако если вас в первую очередь интересует именно MS SQL Server и его характерные нагрузки и особенности, там же, на сайте MS TechNet можно найти программу SQLIOSim

image

Тестирование FCoE и iSCSI на FAS3170

Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
Измерялся FCoE и iSCSI по 10G Ethernet.

Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
http://www.netapp.com/us/library/research-papers/rp-unified-networking-evaluation.html

Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.

Oracle на NetApp – вся библиотека techlibrary

Уверен, вы уже знакомы с черезвычайно полезны ресурсом на сайте NetApp, сборником справочной литературы, Best Practices, и рекомендаций по многочисленным областям применений систем хранения NetApp. Расположен он вот по этому адресу: http://www.netapp.com/us/library/

А ниже собраны для примера все документы NetApp касающиеся только одного продукта – СУБД Oracle.

Возможно практическим dba такая подборка будет полезна, а остальных впечатлит размерами :)

NetApp Best Practices
http://media.netapp.com/documents/tr-3369.pdf  Best Practices for Oracle (through 10g)
http://media.netapp.com/documents/tr-3633.pdf  Best Practices for 11g
http://media.netapp.com/documents/tr-3761.pdf  Best Practices for SnapManager 3
http://media.netapp.com/documents/tr-3426.pdf  SnapManager with 10g RAC Grid
http://media.netapp.com/documents/tr-3442.pdf  SAP on Unix and Oracle with NFS
http://media.netapp.com/documents/ra-0002.pdf  Test/Dev Reference Architecture with Data Guard
http://media.netapp.com/documents/tr-3803.pdf  Oracle VM Best Practices

Performance
http://media.netapp.com/documents/tr-3700.pdf  Oracle 11g Protocol Performance on Linux
http://media.netapp.com/documents/tr-3495.pdf  Storage Protocol Performance on Linux
http://media.netapp.com/documents/tr-3408.pdf  Storage Protocol Performance on AIX
http://media.netapp.com/documents/tr-3496.pdf  Storage Protocol Performance on Solaris
http://media.netapp.com/documents/tr-3322.pdf  Oracle NFS Performance on Solaris
http://media.netapp.com/documents/tr-3557.pdf  HP-UX NFS Performance on 10g
http://media.netapp.com/documents/tr-3357.pdf  Oracle 9i RAC OLTP performance on iSCSI
http://media.netapp.com/documents/tr-3753.pdf  OLTP Performance with NetApp Performance Acceleration Module
http://media.netapp.com/documents/tr-3622.pdf  11g Single Instance Sequential Workload Performance with DNFS and iSCSI on Windows
http://media.netapp.com/documents/tr-3628.pdf  Sequential Workload Performance with iSCSI and NFS

Data Protection
http://media.netapp.com/documents/tr-3520.pdf  SAP Data Protection for Unix on Fibre Channel
http://media.netapp.com/documents/tr-3211.pdf  Data Protection for 9i on Windows
http://media.netapp.com/documents/tr-3368.pdf  Data Protection for 10g on Asianux
http://media.netapp.com/documents/tr-3377.pdf  Oracle with NetApp Open Systems SnapVault (OSSV)

Applications
http://media.netapp.com/documents/tr-3444.pdf  SAP on Microsoft Windows with NetApp
http://media.netapp.com/documents/tr-3533.pdf  SAP on Unix with Fibre Channel
http://media.netapp.com/documents/tr-3391.pdf  Oracle E-Business Suite on NetApp
http://media.netapp.com/documents/tr-3797.pdf  SAP TDMS (Test Data Migration Server) on NetApp
http://media.netapp.com/documents/tr-3300.pdf  Cloning Oracle E-Business Suite with SnapMirror
http://media.netapp.com/documents/tr-3366.pdf  SAP Data Protection on Oracle on Windows
http://media.netapp.com/documents/tr-3365.pdf  SAP Data Protection on Unix and NFS
http://media.netapp.com/documents/tr-3672.pdf  Fusion Middleware Disaster Recovery

Real Applicaiton Clusters
http://media.netapp.com/documents/tr-3572.pdf  Oracle 10gR2 NFS Setup
http://media.netapp.com/documents/tr-3572.pdf  Oracle 10g RAC with ASM on NFS
http://media.netapp.com/documents/tr-3349.pdf  Oracle 10g RAC with ASM on iSCSI
http://media.netapp.com/documents/tr-3189.pdf  Oracle 9i RAC on Red Hat 3
http://media.netapp.com/documents/tr-3413.pdf  Oracle 10g RAC on SUSE
http://media.netapp.com/documents/tr-3536.pdf  Oracle 10g RAC on SUSE9
http://media.netapp.com/documents/tr-3555.pdf  Oracle 10g RAC Cluster Synchronization Services with NetApp
http://media.netapp.com/documents/tr-3527.pdf  Oracle 10g with Power Linux (RHEL AS4 U3)
http://media.netapp.com/documents/tr-3542.pdf  Oracle 10g RAC on AIX
http://media.netapp.com/documents/tr-3479.pdf  Oracle 10g RAC on AIX
http://media.netapp.com/documents/tr-3330.pdf  Oracle 10g RAC with RHEL 3
http://media.netapp.com/documents/tr-3389.pdf  Oracle RAC for HP Service Guard/HP LVM over Fibre Channel
http://media.netapp.com/documents/tr-3399.pdf  Oracle RAC on IBM HACMP SAN

DNFS
http://media.netapp.com/documents/tr-3614.pdf  HA for Oracle with DNFS on NetApp MetroCluster

Disaster Recovery
http://media.netapp.com/documents/tr-3455.pdf  Disaster Recovery for Oracle on NetApp
http://media.netapp.com/documents/tr-3639.pdf  Disaster Recovery with Sun Cluster and NetApp MetroCluster

Misc
http://media.netapp.com/documents/tr-3646.pdf  Oracle 11g with VMWare
http://media.netapp.com/documents/tr-3803.pdf  Upgrading to 11g leveraging SnapMirror, FlexClone, and Real Applicaiton Testing
http://media.netapp.com/documents/tr-3762.pdf  Oracle Data Masking with SnapManager for Oracle
http://media.netapp.com/documents/tr-3792.pdf  Database Migration to Large ONTAP 8.0 Aggregates
http://media.netapp.com/documents/tr-3414.pdf  Ensuring Oracle Data Integrity with NetApp SnapValidator
http://media.netapp.com/documents/tr-3469.pdf  Enterprise Manager plug-in for NetApp
http://media.netapp.com/documents/tr-3781.pdf  NetApp with Oracle ILM Assistant
http://media.netapp.com/documents/tr-3791.pdf  Leveraging Transportable Tablespaces with Flexclones
http://media.netapp.com/documents/tr-3575.pdf  Oracle 10g with Decru DataFort on RHEL 4 on FCP

Best Practices по NetApp - по-русски.

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

На сегодня уже сделаны, можно пойти и почитать:

Разработка файловой системы для специализированного файлсервера NFS
Dave Hitz, James Lau, & Michael Malcolm
Фундаментальная работа 1993 года, описывающая основу основ внутреннего мира систем NetApp, то, с чего собственно все и началось - ту самую, для многих загадочную, “файловую систему” WAFL, Write Anywhere File Layout.
Описание общее, но поможет разобраться в главном.

Поддержка систем NetApp. Руководство пользователя
Global Services | NetApp
Руководство и настольная книга админа системы хранения. Вкратце и понятно о том, что входит в понятие “поддержка” того или иного уровня, как оказывается, “куда бежать и кому звонить”, в случае чего. Как создать кейс, как изменить его статус, полезные ссылки и правила.

Руководство по наилучшим способам использования систем NetApp с Oracle
Eric Barrett, Bikash R. Choundhury, Bruce Clarke | NetApp | TR 3369
Несколько устаревшее, но все равно во многом полезное руководство по настройке и использованию систем хранения NetApp под базы данных Oracle на разных платформах: Windows, Linux, Solaris, и других. Полезные советы и рекомендации по настройкам.

Руководство по наилучшим способам использования систем NetApp с VMware Virtual Infrastructure 3
M. Vaughn Stewart, Michael Slisinger, Larry Touchette, | NetApp | TR 3428
Пусть и не по наиболее свежей версии - vSphere (этот перевод появится в следующем году) но все равно чрезвычайно полезное, всеобъемлющее руководство наилучших практик по использованию систем хранения NetApp для хранения данных виртуальных инфраструктур.
Полезные советы, тонкая настройка, особенности установки и настройки как на стороне системы хранения, так и на стороне VMware ESX/VI.

Использование FlexClone для создания клонов файлов и LUN
Uday Boppana | NetApp | Октябрь 2009 | TR 3742
Одна из краеугольных и фундаментальных технологий современных систем NetApp - возможность создания клонов данных - расширена в версии 7.3.1. Теперь клонировать не занимая на диске места можно не только том целиком, но и отдельный файл, LUN, и даже, при определенных условиях, отдельный файл внутри LUN!

Использование Thin Provisioning в системах хранения NetApp
Rick Jooss | Январь 2008 | TR-3483
Продолжая тему фундаментальных технологий, помогающих экономить пространство на дисках, сокращать затраты и повышать степень использования оборудования - технология Thin Provisioning, встроенная в все системы хранения NetApp, поможет экономно распределять место на дисках в соответствии с потребностями задач - столько сколько нужно, ни больше, ни меньше.

Руководство по установке и настройке дедупликации в системах NetApp FAS и V-Series
Carlos Alvarez | NetApp | TR-3505-0309
И если уж мы заговорили о передовых и уникальных технологиях NetApp, то невозможно пройти мимо по прежнему уникального на рынке предложения - дедупликации на “боевых”, рабочих, primary системах. Средства, позволяющего NetApp гарантировать, что, при использовании его на данных виртуальных сред, экономия объемов хранения по сравнению с любым конкурентом, составит по меньшей мере 50%!
Средства, бесплатно поставляющегося с любой системой хранения NetApp.
В документе подробное описание его работы, а также советы по установке, настройке, и примению с разными прикладными системами.

Руководство по сайзингу для SQL Server 2005/2008 и систем хранения NetApp
John S. Parker | NetApp | TR-3779
Документ, наиболее полезный специалистам по конфигурированию NetApp, рассказывает о деталях сайзинга - количественного анализа и расчета производительности системы хранения NetApp, хранящей базы данных MS SQL Server 2005.

Руководство по наилучшим методам использования систем хранения NetApp с MS Exchange 2007
Brad Garvey, Shannon Flynn | NetApp | TR 3578
Также не обойден вниманием и другой популярнейший продукт Microsoft - всеобъемлющая “система передачи сообщений”, ставшая дефакто стандартом в корпоративном мире - MS Exchange 2007. Рассмотрены рекомендации и наилучшие решения по настройке и использованию этой системы на хранилищах NetApp, оптимизация производительности и использование средсв обеспечения надежности и высокой готовности.

Руководство владельца

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

  • Что входит в поддержку для разных ее уровней
  • Как настроить службу Autosupport
  • Как открыть кейс в NOW (NetApp on Web)
  • Что такое “уровень кейса”, как его поднять в случае необходимости
  • При каки случаях какие действия следует предпринимать для наилучшей скорости реакции
  • Полезные ссылки на файлы и документы на сайте NOW
  • Наилучшие методы решения той или иной задачи
  • …многое другое

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

Подробнее о Data Motion

NetApp Data Motion – новая технология “непрерывающей” миграции данных между системами хранения NetApp. Эта технология несколько напоминает VMware vMotion, но для хранилищ данных, при которой виртуальные машины могут, не прерывая работы, мигрировать между хост-серверами, например в зависимости от их загрузки, или состояния. Это также чем-то похоже на VMware Storage vMotion, но выполняется целиком “аппаратно”, средствами системы хранения, и не привязано к какому-либо софтверному решению на хостах.

Она объявлена для версий новой “линейки” Generation 8, но в январе выйдет и в “Classic”, “Generation 7”, в версию Data ONTAP 7.3.3, для тех, кто вынужден оставаться на старой линейке.

Для работы NetApp Data Motion необходимы следующие компоненты и лицензии:

  1. Multistore – лицензия позволяющая создавать на контроллере NetApp так называемые vFilers, “виртуальные файлеры”, изолированные, виртуализованные средствами самого NetApp ONTAP, “псевдофайлеры”. Раньше эта лицензия обычно использовалась для того, чтобы разделить физический “файлер” на несколько “виртуальных”, например для того, чтобы подключить его в многодоменную CIFS-сеть, или раздать такие “виртуальные файлеры” различным администраторам подразделений в крупной организации или компании-провайдере услуг хранения. Однако идея NetApp, стоящая за Multistore была куда шире.
  2. SnapMirror в режиме Semi-sync – лицензия на средство репликации данных между системами хранения NetApp, осуществляемое, в данном случае, в “квази-синхронном” режиме, по IP-сети.
  3. Средство управления Provisioning Manager версии 4, являющееся частью продукта Operations Manager v.4. Это сравнительно новый для пользователя продукт, обеспечивающий GUI-управление, в том числе и процессом Data Motion, размещающийся на администраторском компьютере.

Процесс миграции заключается в предварительной репликации данных с одной физической системы хранения, где находится мигрируемый vFiler, на другую, когда предварительная baseline replication завершена, то, с помощью Provisioning Manager-а администратор может отдать команду, и vFiler “переключится” с одного контроллера на другой, на котором уже к тому времени будут находиться его данные, при этом ресурсы, такие как, естественно, данные, адреса, имена шар, LUN и их маппинг, также смигрируют вслед за vFiler.

Пока технология не лишена недостатков и ограничений.

  1. Пока не поддерживаются LUN с работой по FC. Но работает iSCSI. Поддержка FC будет реализована позднее в 2010 году. Разумеется работает NFS и CIFS, однако, в случае CIFS, текущая, на момент миграции, сессия CIFS будет прервана, и ее надо будет переустановить (что связано со stateful-природой CIFS как протокола).
  2. Необходимо, чтобы оба контроллера, и источник и получатель миграции,  находились в одной IP-подсети.
  3. Оба контроллера (пока) должны быть однотипными, в случае неоднотипности, миграция возможна с контроллера с меньшим размером NVRAM на бОльший (но в этом случае миграция будет однонаправленная). Также (пока) не поддерживается вариант миграции данных с FC/SAS-дисков на SATA.
  4. Естественно не поддерживаются traditional volumes (кто-то их использует по доброй воле еще?).
  5. Мигрируются все тома, принадлежащие данному vFiler.
  6. SnapLock и FlexCache (пока) не поддерживаются.
  7. Дедуплицированные данные переносятся дедуплицированными, и сохраняют доступность в своем дедуплицированном виде, но соответствующие им метаданные на “получателе” репликации надо заново перегенерировать, чтобы новые записываемые данные могли также дедуплицироваться вместе со старыми, так как метаданные (база фингерпринтов) остаются на уровне aggregate, и не мигрируют.
  8. Мигрированные FlexClones - “развернутся”, “девиртуализируются”, и займут “положенное им по объему” (это, к сожалению, свойство их репликации с помощью SnapMirror).
  9. Пока управление процессами Data Motion возможно только через GUI Operations Manager-а, не через командную строку.

Будем надеяться, что значительная часть ограничений, присущих любому продукту “версии 1.0” со временем будет устранена. Сама же Data Motion это логичный шаг в направлении глобальной стратегии NetApp – построении “облачного” распределенного хранилища, с глобальным “пространством хранения”, распределенным и прозрачно мигрирующим между множеством различных физических хранилищ.

В основу поста легла заметка в блоге Аарона Делпа, по новостям с NetApp Insight 2009, и презентации Ларри Туше, инженера “команды виртуализации” NetApp.

FAS2040 – праздник на “улице” систем “малого класса”.

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, если вас душила жаба – посмотрите, может уже можно договориться ;)

image

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

image

Контроллер – взаимозаменяемый с 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 датчиков температуры жестких дисков, чтобы понять корреляцию между температурой и вероятностью отказов.

image

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

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

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

image

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

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

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

S.M.A.R.T – Self-Monitoring, Analysis and Reporting Tool. Насколько он полезен?

Являющиеся частью стандарта 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, и не имевших таких, по всем рассмотренным возрастным группам.

image

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

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

image

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

image

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

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

image

Вероятность отказа в зависимости от количества ошибок 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, но также явно фиксировался.

image

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

image

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

image

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

 image

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

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

image

Сводный график зарегистрированных 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 – что это?

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

DS4243 – 24TB в 4U!

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

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

DS4243

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

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

image

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

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

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

image

Вид дисковой полки сзади. Для варианта с дисками 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, хотя диски при этом и те же самые, однако просто снять их и переставить в новую полку нельзя.

23/1.424