- LSI MegaRAID SAS 9260-8i
- Настройка мониторинга RAID LSI MegaRaid на Linux с помощью Zabbix
- Установка megacli
- CentOS
- Ubuntu
- Использование megacli
- Скрипты для получения состояния дисков
- UserParameter для агента Zabbix
- Настройка сервера Zabbix
- Создание шаблона
- Применение шаблона
- LSI MegaRAID SAS 9260-8i — недорогой 8-портовый SAS-контроллер
- Контроллер LSI MegaRAID SAS 9260-8i
- Тестирование
- Результаты тестирования
- Тесты в IOmeter
- Ценовая информация
- Заключение
LSI MegaRAID SAS 9260-8i
Может кто-нибудь поделиться SPD выгруженным с сабжа?
С работающей железки, которую нельзя выключать и перегружать, его как-нибудь можно снять?
Под Linux работающих утилит нет, насколько мне известно. Под DOS вынимается с помощью megarec
Попробую, насколько я понимаю, вы это не выкладывали, а нашли. Поделитесь мастерством, по каким ключевым словам это нашлось?
Когда-то давно скачал и у меня на компьютере остался каталог FW_2.120.53-1235 Тогда я перешивал IBM контроллер в родной LSI.
Тогда задам ещё вопрос: очистил флеш, залил sbr, залил spd, прошил lsi fw, а контроллер все равно себя называет ibm m5015. Куда копать?
Сам спросил, сам отвечаю. Готовим файлик.
А подскажи какие ID нужны для IBM M5015? Прошиваю в обратном порядке с LSI на IBM, но контроллер так же называет себя LSI
нашел. прикреплю на всякий случай, может кому поможет SUBVENDORID SUBDEVICEID 1000 9260 MegaRAID SAS 9260-4i 1000 9261 MegaRAID SAS 9260-8i 1000 9267 MegaRAID SAS 9260CV-4i 1000 9268 MegaRAID SAS 9260CV-8i 1000 9280 MegaRAID SAS 9280-8e 1014 03b2 Контроллер ServeRAID M5015 SAS / SATA 1014 03b3 Контроллер ServeRAID M5025 SAS / SATA Адаптер 1028 1f15 PERC H800 Адаптер 1028 1f16 PERC H700 1028 1f17 PERC H700 Интегрированный 1028 1f18 PERC H700 Modular 1043 8480 ПИКЕ-2108 16ПД 1734 1176 RAID Ctrl SAS 6G 5/6 512 МБ (D2616) 1734 1177 RAID Ctrl SAS 6G 0/1 (D2607) 8086 350b RMS2MH080 RAID-контроллер 8086 9260 RAID-контроллер RS2BL040 8086 9261 RAID-контроллер RS2BL080
Источник
Настройка мониторинга RAID LSI MegaRaid на Linux с помощью Zabbix
Разберем ситуацию, при которой нам нужно узнать состояние дискового RAID-массива, затем настроить мониторинг данного состояния сервером Zabbix. В качестве операционной системы, под управлением которой работает компьютер с LSI MegaRaid будем использовать Linux.
Установка megacli
Смотреть состояние массива RAID будем с помощью фирменной утилиты megacli.
Для начала, проверим, что на сервере используется контроллер LSI MegaRaid:
lspci -nn | grep -i lsi
02:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] [1000:0079] (rev 05)
Разберем процесс установка утилиты на Linux CentOS и Ubuntu.
CentOS
Устанавливаем пакеты для распаковки архивов и загрузки файлов:
yum install unzip wget
Переходим по ссылке download.hetzner.de/tools/LSI/tools/MegaCLI — логин hetzner и пароль download. В открывшемся окне копируем ссылку на нужную версию утилиты, например:
С помощью ссылки скачиваем утилиту на компьютер, на котором будет мониторить состояние контроллера:
wget —user hetzner —password download https://download.hetzner.de/tools/LSI/tools/MegaCLI/8.07.10_MegaCLI_Linux.zip
* в данном примере мы загружаем MegaCLI версии 8.07.10 для Linux. Для прохождения авторизации используем логин и пароль hetzner/download.
* если система вернет ошибку при выполнении команды, устанавливаем wget командой yum install wget.
Распаковываем скачанный архив:
rpm -i 8.07.10_MegaCLI_Linux/Linux\ MegaCLI\ 8.07.10/MegaCli-8.07.10-1.noarch.rpm
* напомню, в данном примере устанавливаем версию 8.07.10.
Создаем ссылку на бинарник:
ln -s /opt/MegaRAID/MegaCli/MegaCli64 /usr/bin/megacli
Проверяем, что утилита работает:
Мы должны получить версию установленного пакета.
Ubuntu
Открываем настройки репозитория:
В самый низ добавляем:
deb http://hwraid.le-vert.net/ubuntu xenial main
* где xenial — выпуск Ubuntu (можно посмотреть командой lsb_release -a).
Обновляем список пакетов:
И устанавливаем megacli:
apt-get install megacli
Проверяем, что утилита работает:
Мы должны получить версию установленного пакета.
Использование megacli
Для работы нам могут быть полезны следующие команды.
1. Посмотреть модели контролера и версию прошивки:
megacli -AdpAllInfo -aAll | grep -E ‘Product Name|Serial No|FW Package Build’
Product Name : RAID Ctrl SAS 6G 5/6 512MB (D2616)
Serial No :
FW Package Build : 12.12.0-0174
2. Состояние дисков:
megacli -PDList -Aall
Enclosure Device ID: 252
Slot Number: 0
Drive’s position: DiskGroup: 2, Span: 0, Arm: 0
Enclosure position: N/A
Device Id: 2
WWN: 50014ee2662dd189
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 931.512 GB [0x74706db0 Sectors]
Non Coerced Size: 931.012 GB [0x74606db0 Sectors]
Coerced Size: 931.0 GB [0x74600000 Sectors]
Sector Size: 0
Logical Sector Size: 0
Physical Sector Size: 0
Firmware state: Online, Spun Up
Device Firmware Level: 1A02
Shield Counter: 0
Successful diagnostics completion on : N/A
SAS Address(0): 0x4433221103000000
Connected Port Number: 1(path0)
Inquiry Data: WD-WCC6Y1NURJ0VWDC WD10EZEX-08WN4A0 02.01A 02
FDE Capable: Not Capable
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: 6.0Gb/s
Link Speed: 6.0Gb/s
Media Type: Hard Disk Device
Drive: Not Certified
Drive Temperature :30C (86.00 F)
PI Eligibility: No
Drive is formatted for PI information: No
PI: No PI
Port-0 :
Port status: Active
Port’s Linkspeed: 6.0Gb/s
Drive has flagged a S.M.A.R.T alert : No
* в данном примере отображено состояние для одного диска. Нам могут быть полезны параметры Firmware state — показывает состояние диска; Drive has flagged a S.M.A.R.T alert — состояние SMART.
Скрипты для получения состояния дисков
В нашем примере мы напишем очень простой скрипт, который будет находить неправильное состояние диска. Если хотя бы один из носителей имеет тревоги по SMART или ошибки в состоянии, скрипт будет возвращать 1. Если проблем нет — 0. Сам скрипт будет написан на bash.
У меня не получилось сделать так, чтобы команда megacli нормально отрабатывала при запуске от zabbix агента, поэтому сам скрипт будет выполняться по крону и результат записывать в отдельный файл, который и будет читать агент заббикса.
Создаем каталог, в который поместим скрипт:
Создаем файл скрипта:
count_errors=`megacli -PDList -Aall | grep -e «S.M.A.R.T alert : Yes» -e «Firmware state: Fail» | wc -l`
if [ $count_errors -gt 0 ]
then
echo 1 > /scripts/scan_result
else
echo 0 > /scripts/scan_result
fi
* это простой скрипт, который получает состояние всех дисков и проверяет, нет ли среди этих состояний тревог от SMART и состояния Failed — результат записывается в переменную count_errors в виде количества найденных проблем. Если значение данной переменной больше 0 (то есть, есть хотя бы одно состояние сбоя), скрипт записывает в файл /scripts/scan_result «1», иначе — «0».
Разрешаем запуск скрипта на выполнение:
chmod +x /scripts/raid_mon_cron.sh
Создадим задание в cron:
* в данном примере мы будем запускать наш скрипт по проверке состояние дисков каждые 5 минут.
Теперь создадим скрипт, который будет запускать zabbix-agent:
* обратите внимание, что скрипт создается в каталоге zabbix-агента. Если в нашей системе его нет, необходима установка — примеры установки для CentOS и Ubuntu.
* все, что делает скрипт — выводит содержимое файла /scripts/scan_result, в котором должно быть либо 0, либо 1.
Разрешаем запуск скрипта на выполнение и зададим владельца zabbix:
chmod 770 /etc/zabbix/zabbix_agentd.d/raid_mon.sh
chown zabbix:zabbix /etc/zabbix/zabbix_agentd.d/raid_mon.sh
Пробуем выполнить скрипты:
В зависимости от ситуации они вернут 0 или 1.
UserParameter для агента Zabbix
Запуск скрипта и передача результата его работы серверу мониторинга выполняется с помощью Zabbix-агента. Для этого необходимо настроить UserParameter.
Открываем настройки агента:
В самый низ добавляем строку:
* в данном случае, мы создаем в zabbix агенте пользовательский параметр с именем raid_mon — при его вызове будет запускаться скрипт /etc/zabbix/zabbix_agentd.d/raid_mon.sh, который мы ранее создали.
systemctl restart zabbix-agent
Если используется SELinux, отключаем его:
sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config
Проверяем работу параметра. Для этого с сервера zabbix выполняем команду:
zabbix_get -s 192.168.0.15 -k raid_mon
* в данном примере мы обращаемся к серверу 192.168.0.15 и запускаем пользовательский параметр raid_mon.
В итоге, мы должны получить такой же ответ, который получили, запустив скрипт локально с компьютера, на котором его создали.
Настройка сервера Zabbix
На сервере zabbix необходимо создать шаблон для сканирования дисков с триггером для получения данных от агента на сервере и в случае 1 выводить тревогу. После необходимо добавить данный шаблон для всех узлов, на которых необходим мониторинг дисков.
Создание шаблона
Открываем веб-панель управления Zabbix. Выполним ряд шагов для достижения цели.
1. Переходим в Настройка — Шаблоны:
Справа сверху кликаем по Создать шаблон:
В открывшемся окне называем шаблон, например, Template Scan RAID — добавляем его в группы, например Linux Servers и Windows Servers (нам никто не мешает также сканировать диски на серверах Windows):
Кликаем по Добавить. Будет создан шаблон.
2. В списке шаблонов находим свой и кликаем для его настройки:
Переходим в Группы элементов данных:
Кликаем по Создать группу элементов данных:
Даем название для группы, например, RAID:
. и кликаем по Добавить. Группа элементов создана.
3. Переходим на вкладку Элементы данных и кликаем по Создать элементы данных:
В открывшемся окне даем название для элемента, например, RAID: Status Monitoring — прописываем ключ raid_mon (тот, что задали в UserParameter) — ставим интервал обновления в 5 минут (так как в кроне мы сканируем состояние каждые 5 минут, проверять чаще нет смысла) — выбираем созданную ранее группу элементов данных (RAID):
. и кликаем по Добавить. Элемент данных добавлен.
4. Создаем триггер — для этого переходим на вкладку Триггеры — кликаем по Создать триггер:
Даем название для триггера, например, RAID: Status Error — меняем значение для важности, например, на Высокая — задаем выражение =1 (триггер должен реагировать на значение равное 1):
Нажимаем Добавить.
Шаблон готов и настроен.
Применение шаблона
Теперь можно применить наш шаблон к узлу. Переходим в Настройка — Узлы сети — выбираем узел, на котором создан скрипт для мониторинга дисков — переходим на вкладку Шаблоны и добавляем созданный нами шаблон:
Нажимаем Обновить.
Мониторинг состояния дисков настроен. При возникновении критического состояния мы увидим проблему «RAID: Status Error».
Источник
LSI MegaRAID SAS 9260-8i — недорогой 8-портовый SAS-контроллер
Видимо, прошли те времена, когда приличный профессиональный 8-портовый RAID-контроллер стоил весьма внушительных денег. Нынче появились решения для интерфейса Serial Attached SCSI (SAS), которые очень даже привлекательны и по цене, и по функциональности, да и в плане производительности. Об одном из них — этот обзор.
Контроллер LSI MegaRAID SAS 9260-8i
Ранее мы уже писали об интерфейсе SAS второго поколения со скоростью передачи 6 Гбит/с и весьма дешевом 8-портовом HBA-контроллере LSI SAS 9211-8i, предназначенном для организации систем хранения данных начального ценового уровня на базе простейших RAID-массивов SAS и SATA-накопителей. Модель же LSI MegaRAID SAS 9260-8i будет классом повыше — она оснащена более мощным процессором с аппаратным обсчетом массивов уровней 5, 6, 50 и 60 (технология ROC — RAID On Chip), а также ощутимым объемом (512 Мбайт) набортной SDRAM-памяти для эффективного кеширования данных. Этим контроллером также поддерживаются интерфейсы SAS и SATA со скоростью передачи данных 6 Гбит/с, а сам адаптер предназначен для шины PCI Express x8 версии 2.0 (5 Гбит/с на линию), чего теоретически почти достаточно для удовлетворения потребностей 8 высокоскоростных портов SAS. И все это — по розничной цене в районе 500 долларов, то есть лишь на пару сотен дороже бюджетного LSI SAS 9211-8i. Сам производитель, кстати, относит данное решение к серии MegaRAID Value Line, то есть экономичным решениям.
Плата LSI SAS 9260-8i имеет низкий профиль (форм-фактор MD2), оснащена двумя внутренними разъемами Mini-SAS 4X (каждый из них позволяет подключать до 4 SAS-дисков напрямую или больше — через порт-мультипликаторы), рассчитана на шину PCI Express x8 2.0 и поддерживает RAID-массивы уровней 0, 1, 5, 6, 10, 50 и 60, динамическую функциональность SAS и мн. др. Контроллер LSI SAS 9260-8i можно устанавливать как в рэковые серверы формата 1U и 2U (серверы классов Mid и High-End), так и в корпуса ATX и Slim-ATX (для рабочих станций). Поддержка RAID производится аппаратно — встроенным процессором LSI SAS2108 (ядро PowerPC на частоте 800 МГц), доукомплектованным 512 Мбайт памяти DDR2 800 МГц с поддержкой ECC. LSI обещает скорость работы процессора с данными до 2,8 Гбайт/с при чтении и до 1,8 Гбайт/с при записи. Среди богатой функциональности адаптера стоит отметить функции Online Capacity Expansion (OCE), Online RAID Level Migration (RLM) (расширение объема и изменение типа массивов «на ходу»), SafeStore Encryption Services и Instant secure erase (шифрование данных на дисках и безопасное удаление данных), поддержку твердотельных накопителей (технология SSD Guard) и мн. др. Опционально доступен батарейный модуль для этого контроллера (с ним максимальная рабочая температура не должна превышать +44,5 градусов Цельсия).
Системный интерфейс | PCI Express x8 2.0 (5 ГТ/с), Bus Master DMA |
Дисковый интерфейс | SAS-2 6 Гбит/с (поддержка протоколов SSP, SMP, STP и SATA) |
Число портов SAS | 8 (2 разъема x4 Mini-SAS SFF8087), поддержка до 128 накопителей через порт-мультипликаторы |
Поддержка RAID | уровни 0, 1, 5, 6, 10, 50, 60 |
Процессор | LSI SAS2108 ROC (PowerPC @ 800 МГц) |
Встроенная кеш-память | 512 Мбайт ECC DDR2 800 МГц |
Энергопотребление, не более | 24 Вт (питание +3,3 В и +12 В от слота PCIe) |
Диапазон температур работы/хранения | 0…+60 °С / −45…+105 °С |
Форм-фактор, габариты | MD2 low-profile, 168×64,4 мм |
Значение MTBF | >2 млн. ч |
Гарантия производителя | 3 года |
Типичные применения LSI MegaRAID SAS 9260-8i производитель обозначил так: разнообразные видеостанции (видео по запросу, видеонаблюдение, создание и редактирование видео, медицинские изображения), высокопроизводительные вычисления и архивы цифровых данных, многообразные серверы (файловый, веб, почтовый, базы данных). В общем, подавляющее большинство задач, решаемых в малом и среднем бизнесе.
В бело-оранжевой коробке с легкомысленно улыбающимся зубастым дамским личиком на «титуле» (видимо, чтобы лучше завлечь бородатых сисадминов и суровых систембилдеров) находится плата контроллера, брекеты для ее установки в корпуса ATX, Slim-ATX и пр., два 4-дисковых кабеля с разъемами Mini-SAS на одном конце и обычным SATA (без питания) — на другом (для подключения до 8 дисков к контроллеру), а также CD с PDF-документацией и драйверами для многочисленных версий Windows, Linux (SuSE и RedHat), Solaris и VMware.
Со специальным аппаратным ключом (он поставляется отдельно) для контроллера LSI MegaRAID SAS 9260-8i доступны программные технологии LSI MegaRAID Advanced Services: MegaRAID Recovery, MegaRAID CacheCade, MegaRAID FastPath, LSI SafeStore Encryption Services (их рассмотрение выходит за рамки данной статьи). В частности, в плане повышения производительности массива традиционных дисков (HDD) при помощи добавленного в систему твердотельного накопителя (SSD) будет полезна технология MegaRAID CacheCade, при помощи которой SSD выступает кешем второго уровня для массива HDD (аналог гибридного решения для HDD), в отдельных случаях обеспечивая повышение производительности дисковой подсистемы до 50 раз. Интерес представляет также решение MegaRAID FastPath, при помощи которого уменьшаются задержка обработки процессором SAS2108 операций ввода-вывода (за счет отключения оптимизации под НЖМД), что позволяет ускорить работу массива из нескольких твердотельных накопителей (SSD), подключенных напрямую к портам SAS 9260-8i.
Операции по конфигурированию, настройке и обслуживанию контроллера и его массивов удобнее производить в фирменном менеджере в среде операционной системы (настройки в меню BIOS Setup самого контроллера недостаточно богаты — доступны только базовые функции). В частности, в менеджере за несколько кликов мышкой можно организовать любой массив и установить политики его работы (кеширование и пр.) — см. скриншоты.
Тестирование
Для знакомства с базовой производительностью LSI MegaRAID SAS 9260-8i (без ключа MegaRAID Advanced Services Hardware Key и сопутствующих технологий) мы использовали пять высокопроизводительных SAS-накопителей со скоростью вращения шпинделя 15 тыс. об/мин и поддержкой интерфейса SAS-2 (6 Гбит/с) — Hitachi Ultrastar 15K600 HUS156030VLS600 емкостью по 300 Гбайт.
Это позволит нам протестировать все базовые уровни массивов — RAID 6, 5, 10, 0 и 1, причем не только при минимальном для каждого из них числе дисков, но и «на вырост», то есть при добавлении диска во второй из 4-канальных SAS-портов чипа ROC. Отметим, что у героя этой статьи есть упрощенный аналог — 4-портовый контроллер LSI MegaRAID SAS 9260-4i на той же элементной базе. Поэтому наши тесты 4-дисковых массивов с тем же успехом применимы и к нему.
Максимальная скорость последовательного чтения/записи полезных данных для Hitachi HUS156030VLS600 составляет около 200 Мбайт/с (см. график). Среднее время случайного доступа при чтении (по спецификациям) — 5,4 мс. Встроенный буфер — 64 Мбайт.
Тестовая система была основана на процессоре Intel Xeon 3120, материнской плате с чипсетом Intel P45 и 2 Гбайт памяти DDR2-800. SAS-контроллер устанавливался в слот PCI Express x16 v2.0. Испытания проводились под управлением операционных систем Windows XP SP3 Professional и Windows 7 Ultimate SP1 x86 (чистые американские версии), поскольку их серверные аналоги (Windows 2003 и 2008 соответственно) не позволяют работать некоторым из использованных нами бенчмарков и скриптов. В качестве тестов использовались программы AIDA64, ATTO Disk Benchmark 2.46, Intel IOmeter 2006, Intel NAS Performance Toolkit 1.7.1, C’T H2BenchW 4.13/4.16, HD Tach RW 3.0.4.0 и за компанию Futuremark PCMark Vantage и PCMark05. Тесты проводились как на неразмеченных томах (IOmeter, H2BenchW, AIDA64), так и на отформатированных разделах. В последнем случае (для NASPT и PCMark) результаты снимались как для физического начала массива, так и для его середины (тома массивов максимально доступной емкости разбивались на два равновеликих логических раздела). Это позволяет нам более адекватно оценивать производительность решений, поскольку самые быстрые начальные участки томов, на которых проводятся файловые бенчмарки большинством обозревателей, зачастую не отражают ситуации на остальных участках диска, которые в реальной работе также могут использоваться весьма активно.
Все тесты проводились пятикратно и результаты усреднялись. Подробнее нашу обновленную методику оценки профессиональных дисковых решений мы рассмотрим в отдельной статье.
Остается добавить, что при данном тестировании мы использовали версию прошивки контроллера 12.12.0-0036 и драйверы версии 4.32.0.32. Кеширование записи и чтения для всех массивов и дисков было активировано. Возможно, использование более современной прошивки и драйверов уберегло нас от странностей, замеченных в результатах ранних тестов такого же контроллера нашими коллегами. В нашем случае подобных казусов не наблюдалось. Впрочем, и весьма сомнительный по достоверности результатов скрипт FC-Test 1.0 (который в определенных случаях тем же коллегам «хочется назвать разбродом, шатанием и непредсказуемостью») мы тоже в нашем пакете не используем, поскольку ранее многократно замечали его несостоятельность на некоторых файловых паттернах (в частности, наборах множества мелких, менее 100 Кбайт, файлов).
На диаграммах ниже приведены результаты для 8 конфигураций массивов:
- RAID 0 из 5 дисков;
- RAID 0 из 4 дисков;
- RAID 5 из 5 дисков;
- RAID 5 из 4 дисков;
- RAID 6 из 5 дисков;
- RAID 6 из 4 дисков;
- RAID 1 из 4 дисков;
- RAID 1 из 2 дисков.
Под массивом RAID 1 из четырех дисков (см. скриншот выше) в компании LSI, очевидно, понимают массив «страйп+зеркало», обычно обозначаемый как RAID 10 (это подтверждают и результаты тестов).
Результаты тестирования
Чтобы не перегружать веб-страницу обзора бесчисленным набором диаграмм, порой малоинформативных и утомляющих (чем нередко грешат некоторые «оголтелые коллеги» :)), мы свели детальные результаты некоторых тестов в таблицу. Желающие проанализировать тонкости полученных нами результатов (например, выяснить поведение фигурантов в наиболее критичных для себя задачах) могут сделать это самостоятельно. Мы же сделаем упор на наиболее важных и ключевых результатах тестов, а также на усредненных показателях.
Сначала взглянем на результаты «чисто физических» тестов.
Среднее время случайного доступа к данным при чтении на единичном диске Hitachi Ultrastar 15K600 HUS156030VLS600 составляет 5,5 мс. Однако при организации их в массивы этот показатель немного меняется: уменьшается (благодаря эффективному кешированию в контроллере LSI SAS9260) для «зеркальных» массивов и увеличивается — для всех остальных. Наибольший рост (примерно на 6%) наблюдается для массивов уровня 6, поскольку при этом контроллеру приходится одновременно обращаться к наибольшему числу дисков (к трем для RAID 6, к двум — для RAID 5 и к одному для RAID 0, поскольку обращение в этом тесте происходит блоками размером всего 512 байт, что существенно меньше размера блоков чередования массивов).
Гораздо интереснее ситуация со случайным доступом к массивам при записи (блоками по 512 байт). Для единичного диска этот параметр равен около 2,9 мс (без кеширования в хост-контроллере), однако в массивах на контроллере LSI SAS9260 мы наблюдаем существенное уменьшение этого показателя — благодаря хорошему кешированию записи в SDRAM-буфере контроллера объемом 512 Мбайт. Интересно, что наиболее кардинальный эффект получается для массивов RAID 0 (время случайного доступа при записи падает почти на порядок по сравнению с одиночным накопителем)! Это несомненно должно благотворно отразиться на быстродействии таких массивов в ряде серверных задач. В то же время, и на массивах с XOR-вычислениями (то есть высокой нагрузкой на процессор SAS2108) случайные обращения на записи не приводят к явному проседанию быстродействия — снова благодаря мощному кешу контроллера. Закнонмерно, что RAID 6 здесь чуть медленнее, чем RAID 5, однако разница между ними, по сути, несущественна. Несколько удивило в этом тесте поведение одиночного «зеркала», показавшего самый медленный случайный доступ при записи (возможно, это «фича» микрокода данного контроллера).
Графики скорости линейного (последовательного) чтения и записи (крупными блоками) для всех массивов не имеют каких-либо особенностей (для чтения и записи они практически идентичны при условии задействования кеширования записи контроллера) и все они масштабируются согласно количеству дисков, параллельно участвующих в «полезном» процессе. То есть для пятидискового RAID 0 дисков скорость «упятеряется» относительно одиночного диска (достигая показателя в 1 Гбайт/с!), для пятидискового RAID 5 она «учетверяется», для RAID 6 — «утрояется» (утраивается, конечно же :)), для RAID 1 из четырех дисков — удваивается (никаких «у2яица»! :)), а для простого зеркала — дублирует графики одиночного диска. Эта закономерность наглядно видна, в частности, по показателям максимальной скорости чтения и записи реальных крупных (256 Мбайт) файлов большими блоками (от 256 Кбайт до 2 Мбайт), что мы проиллюстрируем диаграммой теста ATTO Disk Benchmark 2.46 (результаты этого теста для Windows 7 и XP практически идентичны).
Здесь из общей картины неожиданно выпал лишь случай чтения файлов на массиве RAID 6 из 5 дисков (результаты многократно перепроверены). Впрочем, для чтения блоками 64 Кбайт скорость данного массива набирает положенные ему 600 Мбайт/с. Так что спишем данный факт на «фичу» текущей прошивки. Отметим также, что при записи реальных файлов скорость чуть повыше благодаря кешированию в большом буфере контроллера, причем разница с чтением тем ощутимее, чем меньше реальная линейная скорость массива.
Что же касается скорости интерфейса, измеряемой обычно по показателям записи и чтения буфера (многократные обращения по одному и тому же адресу дискового тома), то здесь мы вынуждены констатировать, что почти для всех массивов она оказалась одинакова благодаря включению кеша контроллера для этих массивов (см. таблицу). Так, показатели при записи для всех участников нашего теста составили примерно 2430 Мбайт/с. Заметим, что шина PCI Express x8 2.0 теоретически дает скорость 40 Гбит/с или 5 Гбайт/с, однако по полезным данным теоретический предел пониже — 4 Гбайт/с, и значит, в нашем случае контроллер действительно работал по версии 2.0 шины PCIe. Таким образом, измеренные нами 2,4 Гбайт/с — это, очевидно, реальная пропускная способность набортной памяти контроллера (память DDR2-800 при 32-битной шине данных, что видно из конфигурации ECC-чипов на плате, теоретически дает до 3,2 Гбайт/с). При чтении же массивов кеширование не столь «всеобъемлюще», как при записи, поэтому и измеряемая в утилитах скорость «интерфейса», как правило, ниже скорости чтения кеш-памяти контроллера (типичные 2,1 Гбайт/с для массивов уровней 5 и 6), и в некоторых случаях она «падает» до скорости чтения буфера самих жестких дисков (около 400 Мбайт/с для одиночного винчестера, см. график выше), помноженной на число «последовательных» дисков в массиве (это как раз случаи RAID 0 и 1 из наших результатов).
Что ж, с «физикой» мы в первом приближении разобрались, пора переходить к «лирике», то есть к тестам «реальных» пацанов приложений. К слову, интересно будет выяснить, масштабируется ли производительность массивов при выполнении комплексных пользовательских задач так же линейно, как она масштабируется при чтении и записи крупных файлов (см. диаграмму теста ATTO чуть выше). Пытливый читатель, надеюсь, уже смог предугадать ответ на этот вопрос.
В качестве «салата» к нашей «лирической» части трапезы подадим десктопные по своей природе дисковые тесты из пакетов PCMark Vantage и PCMark05 (под Windows 7 и XP соответственно), а также похожий на них «трековый» тест приложений из пакета H2BenchW 4.13 авторитетного немецкого журнала C’T. Да, эти тесты исходно создавались для оценки жестких дисков настольных ПК и недорогих рабочих станций. Они эмулируют выполнение на дисках типичных задач продвинутого персонального компьютера — работу с видео, аудио, «фотошопом», антивирусом, играми, своп-файлом, установкой приложений, копированием и записью файлов и др. Поэтому и их результаты в контексте данной статьи не стоит воспринимать как истину в последней инстанции — все-таки на многодисковых массивах чаще выполняются иные задачи. Тем не менее, в свете того, что сам производитель позиционирует данный RAID-контроллер, в том числе, для относительно недорогих решений, подобный класс тестовых задач вполне способен характеризовать некоторую долю приложений, которые в реальности будут выполняться на таких массивах (та же работа с видео, профессиональная обработка графики, свопирование ОС и ресурсоемких приложений, копирование файлов, анитивирус и пр.). Поэтому и значение этих трех комплексных бенчмарков в нашем общем пакете не стоит недооценивать.
В популярном PCMark Vantage в среднем (см. диаграмму) мы наблюдаем очень примечательный факт — производительность данного многодискового решения почти не зависит от типа используемого массива! К слову, в определенных пределах это вывод справедлив и для всех отдельных тестовых треков (типов задач), входящих в состав пакетов PCMark Vantage и PCMark05 (детали см. в таблице). Это может означать либо то, что алгоритмы прошивки контроллера (с кешем и дисками) почти не учитывают специфику работы приложений подобного типа, либо то, что основная часть данных задач выполняется в кеш-памяти самого контроллера (а скорее всего мы наблюдаем комбинацию этих двух факторов). Впрочем, для последнего случая (то есть выполнения треков в большой мере в кеше RAID-коннтроллера) средняя производительность решений оказывается не такой уж высокой — сравните эти данные с результатами тестов некоторых «десктопных» («чипсетаных») 4-дисковых массивов RAID 0 и 5 и недорогих одиночных SSD на шине SATA 3 Гбит/с (см. обзор). Если по сравнению с простым «чипсетным» 4-дисковым RAID 0 (причем на вдвое более медленных винчестерах, чем примененные здесь Hitachi Ultrastar 15K600) массивы на LSI SAS9260 быстрее в тестах PCMark менее чем вдвое, то относительно даже не самого быстрого «бюджетного» одиночного SSD все они однозначно проигрывают! Результаты дискового теста PCMark05 дают аналогичную картину (см. табл.; рисовать отдельную диаграмму для них смысла нет).
Похожую картину (с отдельными оговорками) для массивов на LSI SAS9260 можно наблюдать в еще одном «трековом» бенчмарке приложений — C’T H2BenchW 4.13. Здесь лишь два наиболее медленных (по строению) массива (RAID 6 из 4 дисков и простое «зеркало») заметно отстают от всех остальных массивов, производительность которых, очевидно, достигает того «достаточного» уровня, когда она упирается уже не в дисковую подсистему, а в эффективность работы процессора SAS2108 c кеш-памятью контроллера при данных комплексных последовательностях обращений. А радовать нас в этом контексте может то, что производительность массивов на базе LSI SAS9260 в задачах такого класса почти не зависит от типа используемого массива (RAID 0, 5, 6 или 10), что позволяет использовать более надежные решения без ущерба для итоговой производительности.
Впрочем, «не все коту Масленица» — если мы изменим тесты и проверим работу массивов с реальными файлами на файловой системе NTFS, то картина кардинально изменится. Так, в тесте Intel NASPT 1.7, многие из «предустановленных» сценариев которого имеют достаточно прямое отношение к задачам, типичным для компьютеров, оснащенных контроллером LSI MegaRAID SAS9260-8i, диспозиция массивов похожа на ту, что мы наблюдали в тесте ATTO при чтении и записи крупных файлов — быстродействие пропорционально нарастает по мере роста «линейной» скорости массивов.
На этой диаграмме мы приводим усредненный по всем тестам и паттернам NASPT показатель, тогда как в таблице можно видеть детальные результаты. Подчеркну, что NASPT прогонялся нами как под Windows XP (так обычно поступают многочисленные обозреватели), так и под Windows 7 (что в силу определенных особенностей этого теста делается реже). Дело в том, что Seven (и ее «старший братец» Windows 2008 Server) используют более агрессивные алгоритмы собственного кеширования при работе с файлами, нежели XP. Кроме того, копирование крупных файлов в «Семерке» происходит преимущественно блоками по 1 Мбайт (XP, как правило, оперирует блоками по 64 Кбайт). Это приводит к тому, что результаты «файлового» теста Intel NASPT существенно различаются в Windows XP и Windows 7 — в последней они намного выше, порой более чем вдвое! К слову, мы сравнили результаты NASPT (и других тестов нашего пакета) под Windows 7 с 1 Гбайт и 2 Гбайт установленной системной памяти (есть информация, что при больших объемах системной памяти кеширование дисковых операций в Windows 7 усиливается и результаты NASPT становятся еще выше), однако в пределах погрешности измерений мы не нашли никакой разницы.
Споры о том, под какой ОС (в плане политик кеширования и пр.) «лучше» тестировать диски и RAID-контроллеры, мы оставляем для ветки обсуждений этой статьи. Мы же считаем, что тестировать накопители и решения на их основе надо в условиях, максимально приближенных к реальным ситуациям их эксплуатации. Именно поэтому равную ценность, на наш взгляд, имеют результаты, полученные нами для обеих ОС.
Но вернемся к диаграмме усредненной производительности в NASPT. Как видим, разница между самым быстрым и самым медленным из протестированных нами массивов здесь составляет в среднем чуть менее трех раз. Это, конечно, не пятикратный разрыв, как при чтении и записи крупны файлов, но тоже весьма ощутимо. Массивы расположились фактически пропорционально своей линейной скорости, и это не может не радовать: значит, процессор LSI SAS2108 достаточно шустро обрабатывает данные, почти не создавая узких мест при активной работе массивов уровней 5 и 6.
Справедливости ради нужно отметить, что и в NASPT есть паттерны (2 из 12), в которых наблюдается та же картина, что и в PCMark c H2BenchW, а именно что производительность всех протестированных массивов практически одинакова! Это Office Productivity и Dir Copy to NAS (см. табл.). Особенно явно это под Windows 7, хотя и для Windows XP тенденция «сближения» налицо (по сравнению с другими паттернами). Впрочем, и в PCMark c H2BenchW есть паттерны, где налицо рост производительности массивов пропорционально их линейной скорости. Так что все не так просто и однозначно, как может некоторым хотелось бы.
Поначалу я хотел обсудить диаграмму с общими показателями быстродействия массивов, усредненными по всем тестам приложений (PCMark+H2BenchW+NASPT+ATTO), то есть вот эту:
Однако обсуждать здесь особо нечего: мы видим, что поведение массивов на контроллере LSI SAS9260 в тестах, эмулирующих работу тех или иных приложений, может кардинально различаться в зависимости от применяемых сценариев. Поэтому выводы о пользе той или иной конфигурации лучше делать, исходя из того, какие именно задачи вы собираетесь при этом выполнять. И в этом нам может заметно помочь еще один профессиональный тест — синтетические паттерны для IOmeter, эмулирующие ту или иную нагрузку на систему хранения данных.
Тесты в IOmeter
В данном случае мы опустим обсуждение многочисленных паттернов, тщательно измеряющих скорость работы в зависимости от размера блока обращения, процента операций записи, процента случайных обращений и пр. Это, по сути, чистая синтетика, дающая мало полезной практической информации и представляющая интерес скорее чисто теоретически. Ведь основные практические моменты касательно «физики» мы уже выяснили выше. Нам важнее сосредоточиться на паттернах, эмулирующих реальную работу — серверов различного типа, а также операций с файлами.
Для эмуляции серверов типа File Server, Web Server и DataBase (сервер базы данных) мы воспользовались одноименными и хорошо известными паттернами, предложенными в свое время Intel и StorageReview.com. Для всех случаев мы протестировали массивы при глубине очереди команд (QD) от 1 до 256 с шагом 2.
В паттерне «База данных», использующих случайные обращения к диску блоками по 8 Кбайт в пределах всего объема массива, можно наблюдать существенное преимущество массивов без контроля четности (то есть RAID 0 и 1) при глубине очереди команд от 4 и выше, тогда как все массивы с контролем четности (RAID 5 и 6) демонстрируют очень близкое быстродействие (несмотря на двукратное различие между ними в скорости линейных обращений). Ситуация объясняется просто: все массивы с контролем четности показали в тестах на среднее время случайного доступа близкие значения (см. диаграмму выше), а именно этот параметр в основном определяет производительность в данном тесте. Интересно, что быстродействие всех массивов нарастает практически линейно с ростом глубины очереди команд вплоть до 128, и лишь при QD=256 для некоторых случаев можно видеть намек на насыщение. Максимальная производительность массивов с контролем четности при QD=256 составила около 1100 IOps (операций в секунду), то есть на обработку одной порции данных в 8 Кбайт процессор LSI SAS2108 тратит менее 1 мс (около 10 млн однобайтовых XOR-операций в секунду для RAID 6; разумеется, процессор при этом выполняет параллельно и другие задачи по вводу-выводу данных и работе с кеш-памятью).
В паттерне файлового сервера, использующего блоки разного размера при случайных обращениях чтения и записи к массиву в пределах всего его объема, мы наблюдаем похожую на DataBase картину с той разницей, что здесь пятидисковые массивы с контролем четности (RAID 5 и 6) заметно обходят по скорости свои 4-дисковые аналоги и демонстрируют при этом почти идентичную производительность (около 1200 IOps при QD=256)! Видимо, добавление пятого диска на второй из двух 4-канальных SAS-портов контроллера каким-то образом оптимизирует вычислительные нагрузки на процессор (за счет операций ввода-вывода?). Возможно, стоит сравнить по скорости 4-дисковые массивы, когда накопители попарно подключены к разным Mini-SAS-разъемам контроллера, чтобы выявить оптимальную конфигурацию для организации массивов на LSI SAS9260, но это уже задача для другой статьи.
В паттерне веб-сервера, где, по замыслу его создателей, отсутствуют как класс операции записи на диск (а значит, и вычисление XOR-функций на запись), картина становится еще интереснее. Дело в том, что все три пятидисковых массива из нашего набора (RAID 0, 5 и 6) показывают здесь идентичное быстродействие, несмотря на заметную разницу между ними по скорости линейного чтения и вычислений по контролю четности! К слову, эти же три массива, но из 4 дисков, также идентичны по скорости друг другу! И лишь RAID 1 (и 10) выпадает из общей картины. Почему так происходит, судить сложно. Возможно, контроллер имеет очень эффективные алгоритмы выборки «удачных дисков» (то есть тех из пяти или четырех дисков, с которых первыми приходят нужные данные), что в случае RAID 5 и 6 повышает вероятность более раннего поступления данных с пластин, заранее подготавливая процессор для нужных вычислений (вспомним про глубокую очередь команд и большой буфер DDR2-800). А это в итоге может скомпенсировать задержку, связанную с XOR-вычислениями и уравнивает их в «шансах» с «простым» RAID 0. В любом случае, контроллер LSI SAS9260 можно только похвалить за экстремально высокие результаты (около 1700 IOps для 5-дисковых массивов при QD=256) в паттерне Web Server для массивов с контролем четности. К сожалению, ложкой дегтя стала весьма низкая производительность двухдискового «зеркала» во всех этих серверных паттернах.
Паттерну Web Server вторит наш собственный паттерн, эмулирующий случайное чтение небольших (64 Кбайт) файлов в пределах всего пространства массива.
Снова результаты объединились в группы — все 5-дисковые массивы идентичны друг другу по скорости и лидируют в нашем «забеге», 4-дисковые RAID 0, 5 и 6 тоже не отличить друг от друга по производительности, и лишь «зеркалки» выпадают из общей массы (к слову, 4 дисковая «зеркалка», то есть RAID 10 оказывается быстрее всех остальных 4-дисковых массивов — видимо, за счет того же самого алгоритма «выбора удачного диска»). Подчеркнем, что данные закономерности справедливы лишь для большой глубины очереди команд, тогда как при малой очереди (QD=1-2) ситуация и лидеры могут быть совсем иными.
Все меняется при работе серверов с крупными файлами. В условиях современного «потяжелевшего» контента и новых «оптимизированных» ОС типа Windows 7, 2008 Server т.п. работа с мегабайтными файлами и блоками данных по 1 Мбайт приобретает все более важное значение. В этой ситуации наш новый паттерн, эмулирующий случайное чтение 1-мегабайтных файлов в пределах всего диска (детали новых паттернов будут описаны в отдельной статье по методике), оказывается как нельзя кстати, чтобы более полно оценить серверный потенциал контроллера LSI SAS9260.
Как видим, 4-дисковое «зеркало» здесь уже никому не оставляет надежд на лидерство, явно доминируя при любой очереди команд. Его производительность также сначала растет линейно с ростом глубины очереди команд, однако при QD=16 для RAID 1 она выходит на насыщение (скорость около 200 Мбайт/с). Чуть «позже» (при QD=32) «насыщение» производительности наступает у более медленных в этом тесте массивов, среди которых «серебро» и «бронзу» приходится отдать RAID 0, а массивы с контролем четности оказываются в аутсайдерах, уступив даже прежде не блиставшему RAID 1 из двух дисков, который оказывается неожиданно хорош. Это приводит нас к выводу, что даже при чтении вычислительная XOR-нагрузка на процессор LSI SAS2108 при работе с крупными файлами и блоками (расположенными случайным образом) оказывается для него весьма обременительна, а для RAID 6, где она фактически удваивается, порой даже непомерна — производительность решений едва превышает 100 Мбайт/с, то есть в 6-8 раз ниже, чем при линейном чтении! «Избыточный» RAID 10 здесь применять явно выгоднее.
При случайной записи мелких файлов картина снова разительно отличается от тех, что мы видели ранее.
Дело в том, что здесь уже производительность массивов практически не зависит от глубины очереди команд (очевидно, сказывается огромный кеш контроллера LSI SAS9260 и немаленькие кеши самих винчестеров), зато кардинально меняется с типом массива! В безоговорочных лидерах тут «простенькие» для процессора RAID 0, а «бронза» с более чем двукратным проигрышем лидеру — у RAID 10. Все массивы с контролем четности образовали очень тесную единую группу с двухдисковой зеркалкой (детали по ним приведены на отдельной диаграмме под основной), троекратно проигрывая лидерам. Да, это, безусловно, тяжелая нагрузка на процессор контроллера. Однако такого «провала» я, откровенно говоря, от SAS2108 не ожидал. Порой даже софтовый RAID 5 на «чипсетом» SATA-контроллере (с кешированием средствами Windows и обсчетом при помощи центрального процессора ПК) способен работать шустрее… Впрочем, «свои» 440-500 IOps контроллер при этом все-таки выдает стабильно — сравните это с диаграммой по среднему времени доступа при записи в начале раздела результатов.
Переход на случайную запись крупных файлов по 1 Мбайт приводит к росту абсолютных показателей скорости (для RAID 0 — почти до значений при случайном чтении таких файлов, то есть 180-190 Мбайт/с), однако общая картина почти не меняется — массивы с контролем четности в разы медленнее RAID 0.
Любопытна картина для RAID 10 — его производительность падает с ростом глубины очереди команд, хотя и не сильно. Для остальных массивов такого эффекта нет. Двухдискове «зеркало» здесь снова выглядит скромно.
Теперь посмотрим на паттерны, в которых файлы в равных количествах читаются и пишутся на диск. Такие нагрузки характерны, в частности, для некоторых видеосерверов или при активном копировании/дуплицировании/резервировании файлов в пределах одного массива, а также в случае дефрагментации.
Сначала — файлы по 64 Кбайт случайным образом по всему массиву.
Здесь очевидно некоторое сходство с результатами паттерна DataBase, хотя абслютные скорости у массивов раза в три повыше, да и при QD=256 уже заметно некоторое насыщение производительности. Больший (по сравнению с паттерном DataBase) процент операций записи в этом случае приводит к тому, что массивы с контролем четности и двухдисковое «зеркало» становятся явными аутсайдерами, существенно уступая по скорости массивам RAID 0 и 10.
При переходе на файлы по 1 Мбайт данная закономерность в целом сохраняется, хотя абсолютные скорости примерно утраиваются, а RAID 10 становится таким же быстрым, как 4-дисковый «страйп», что не может не радовать.
Последним паттерном в этой статье будет случай последовательного (в противовес случайным) чтения и записи крупных файлов.
И тут уже многим массивам удается разогнаться до весьма приличных скоростей в районе 300 Мбайт/с. И хотя более чем двукратный разрыв между лидером (RAID 0) и аутсайдером (двухдисковый RAID 1) сохраняется (заметим, что при линейном чтении ИЛИ записи этот разрыв пятикратен!), вошедший в тройку лидеров RAID 5, да и подтянувшиеся остальные XOR-массивы не могут не обнадеживать. Ведь если судить по тому перечню применений данного контроллера, который приводит сама LSI (см. начало статьи), многие целевые задачи будут использовать именно данный характер обращений к массивам. И это определенно стоит учитывать.
В заключение приведу итоговую диаграмму, в которой усреднены показатели всех озвученных выше паттернов теста IOmeter (геометрически по всем паттернам и очередям команд, без весовых коэффициентов). Любопытно, что если усреднение данных результатов внутри каждого паттерна проводить арифметически с весовыми коэффициентами 0,8, 0,6, 0,4 и 0,2 для очередей команд 32, 64, 128 и 256 соответственно (что условно учитывает падение доли операций с высокой глубиной очереди команд в общей работе накопителей), то итоговый (по всем паттернам) нормированный индекс быстродействия массивов в пределах 1% совпадет со средним геометрическим.
Итак, средняя «температура по больнице» в наших паттернах для теста IOmeter показывает, что от «физики с матемачихой» никуда не уйти — однозначно лидируют RAID 0 и 10. Для массивов с контролем четности чуда не произошло — процессор LSI SAS2108 хоть и демонстрирует в некоторых случаях приличную производительность, в целом не может «дотянуть» такие массивы до уровня простого «страйпа». При этом интересно, что 5-дисковые конфигурации явно прибавляют по сравнению с 4 дисковыми. В частности, 5-дисквый RAID 6 однозначно быстрее 4-дискового RAID 5, хотя по «физике» (времени случайного доступа и скорости линейного доступа) они фактически идентичны. Также огорчило двухдисковое «зеркало» (в среднем оно равноценно 4-дисковому RAID 6, хотя для зеркала двух XOR-вычислений на каждый бит данных не требуется). Впрочем, простое «зеркало» — это очевидно не целевой массив для достаточно мощного 8-портового SAS-контроллера с большим кешем и мощным процессором «на борту». 🙂
Ценовая информация
8-портовый SAS-контроллер LSI MegaRAID SAS 9260-8i с полным комплектом предлагается по цене в районе 500 долларов, что можно считать достаточно привлекательным. Его упрощенный 4-портовый аналог еще дешевле. Более точная текущая средняя розничная цена устройства в Москве, актуальная на момент чтения вами данной статьи:
LSI SAS 9260-8i | LSI SAS 9260-4i |
---|---|
$571(33) | $386(30) |
Заключение
Суммируя сказано выше, можно заключить, что единых рекомендаций «для всех» по 8-портовому контроллеру LSI MegaRAID SAS9260-8i мы давать не рискнем. О необходимости его использования и конфигурирования тех или иных массивов с его помощью каждый должен делать выводы самостоятельно — строго исходя из того класса задач, которые предполагается при этом запускать. Дело в том, что в одних случаях (на одних задачах) этот недорогой «мегамонстр» способен показать выдающуюся производительность даже на массивах с двойным контролем четности (RAID 6 и 60), однако в других ситуациях скорость его RAID 5 и 6 явно оставляет желать лучшего. И спасением (почти универсальным) станет лишь массив RAID 10, который почти с тем же успехом можно организовать и на более дешевых контроллерах. Впрочем, нередко именно благодаря процессору и кеш-памяти SAS9260-8i массив RAID 10 ведет себя здесь ничуть не медленнее «страйпа» из того же числа дисков, обеспечивая при этом высокую надежность решения. А вот чего однозначно стоит избегать с SAS9260-8i, так это двухдисковой «зеркалки» и 4-дисковых RAID 6 и 5 — для данного контроллера это очевидно неоптимальные конфигурации.
Источник