Привет, %хабрачитатель%!
Несколько месяцев назад у нас возникли проблемы с одной виртуальной машиной, запущенной на сервере Dell PowerEdge R720 с ESXi 5.5. Перезагрузка этой VM длилась довольно долго и вызвала сильное падение производительности на самом хосте.
Lifecycle-лог на сервере был наполнен сообщениями вида:
Гугление привело к неутешительному выводу: рейд-массив поврежден и восстановить его невозможно. А именно — повредились данные, относящиеся к одному блоку (страйпу), сразу на нескольких дисках (double fault):
К счастью, делловские RAID-контроллеры обладают фичей продолжать работу, несмотря на неконсисентное состояние массива — puncture (https://www.dell.com/support/Article/us/en/04/438291/EN#Unique-Hyphenated-Issue-Here-2), что позволяет сохранить хотя бы ту часть данных, которая не повредились. Это, конечно, не никак отменяет необходимость последующей замены дисков и пересборки рейд-массива «с нуля».
Для предотвращения подобных ситуаций Dell рекомендует запускать проверку целостности массива не реже одного раза в месяц. Увы, но мы об этом узнали слишком поздно.
Такую проверку можно запускать как через веб-интерфейс Dell OpenManage Server Administrator (http://www.dell.com/support/contents/us/en/19/article/Product-Support/Self-support-Knowledgebase/enterprise-resource-center/Enterprise-Tools/OMSA/), так и через утилиты omconfig/omreport, входящие в OMSA. И, если бы разработчики из Dell не «забыли» включить эти утилиты в OpenManage для ESXi, то проблем с автоматизацией бы не возникло, т.к. понятно, что ручная проверка целостности массива на каждом сервере, совершенно не IT-way. Не говоря уже о том, что интерфейс OMSA очень медленный и работать с ним удовольствие еще то.
Ребята из Dell «поработали на славу» и простым способом автоматизировать проверку (например, через открытие в cURL заранее подготовленной ссылки) невозможно, т.к. веб-интерфейс генерируется динамически и постоянные ссылки в нем отсутствуют.
Что же делать?
Пришлось немного повозиться и написать утилиту проверки самому. Встречайте: Consistency Check Task Automation Tool for Dell servers with iDRAC (https://github.com/jazzl0ver/dell_raid_cc). Утилита написана с помощью фреймворка CasperJS, который позволяет автоматизировать работу как раз с подобными динамическими сайтами.
Для использования dell_raid_cc необходимо:
1. Сервер с установленным OMSA (см. ссылку выше)
2. Скачать и установить phantomjs (http://phantomjs.org/download.html)
3. Скачать и установить casperjs (http://docs.casperjs.org/en/latest/installation.html)
4. Вытащить утилиту из git:
5. Создать файл с параметрами доступа (например, creds.txt):
6. Загрузить его и можно запускать утилиту или ставить ее запуск в кронтаб:
Если все в порядке, то вывод будет примерно такой:
Если запустить еще раз, можно увидеть прогресс проверки, например:
Стоит сказать, что утилита не поддерживает многоконтроллерные системы (у меня просто таких нет и протестировать, соответственно, не на чем).
Надеюсь, утилита окажется полезной не только мне.
UPD. Как подсказали коллеги в комментариях, более правильно настроить запуск проверки на целостность по расписанию с помощью утилиты megacli. Например:
Инструкции по установке на сервер с CentOS/RedHat — здесь
Настройка расписания CC — здесь
Под ESXi также легко устанавливается. Можно поставить vib напрямую, либо сделать из него bundle и поставить в качестве обновления через vCenter.
UPD. #2 Контроллеры Perc5 не поддерживают настройку расписания через MegaCli:
Для них использование dell_raid_cc — единственный способ автоматизации.
Несколько месяцев назад у нас возникли проблемы с одной виртуальной машиной, запущенной на сервере Dell PowerEdge R720 с ESXi 5.5. Перезагрузка этой VM длилась довольно долго и вызвала сильное падение производительности на самом хосте.
Lifecycle-лог на сервере был наполнен сообщениями вида:
PDR47
A block on Disk 0 in Backplane 1 of Integrated RAID Controller 1 was
punctured by the controller.
PDR64
An unrecoverable disk media error occurred on Disk 0 in Backplane 1 of
Integrated RAID Controller 1.
Гугление привело к неутешительному выводу: рейд-массив поврежден и восстановить его невозможно. А именно — повредились данные, относящиеся к одному блоку (страйпу), сразу на нескольких дисках (double fault):
К счастью, делловские RAID-контроллеры обладают фичей продолжать работу, несмотря на неконсисентное состояние массива — puncture (https://www.dell.com/support/Article/us/en/04/438291/EN#Unique-Hyphenated-Issue-Here-2), что позволяет сохранить хотя бы ту часть данных, которая не повредились. Это, конечно, не никак отменяет необходимость последующей замены дисков и пересборки рейд-массива «с нуля».
Для предотвращения подобных ситуаций Dell рекомендует запускать проверку целостности массива не реже одного раза в месяц. Увы, но мы об этом узнали слишком поздно.
Такую проверку можно запускать как через веб-интерфейс Dell OpenManage Server Administrator (http://www.dell.com/support/contents/us/en/19/article/Product-Support/Self-support-Knowledgebase/enterprise-resource-center/Enterprise-Tools/OMSA/), так и через утилиты omconfig/omreport, входящие в OMSA. И, если бы разработчики из Dell не «забыли» включить эти утилиты в OpenManage для ESXi, то проблем с автоматизацией бы не возникло, т.к. понятно, что ручная проверка целостности массива на каждом сервере, совершенно не IT-way. Не говоря уже о том, что интерфейс OMSA очень медленный и работать с ним удовольствие еще то.
Ребята из Dell «поработали на славу» и простым способом автоматизировать проверку (например, через открытие в cURL заранее подготовленной ссылки) невозможно, т.к. веб-интерфейс генерируется динамически и постоянные ссылки в нем отсутствуют.
Что же делать?
Пришлось немного повозиться и написать утилиту проверки самому. Встречайте: Consistency Check Task Automation Tool for Dell servers with iDRAC (https://github.com/jazzl0ver/dell_raid_cc). Утилита написана с помощью фреймворка CasperJS, который позволяет автоматизировать работу как раз с подобными динамическими сайтами.
Для использования dell_raid_cc необходимо:
1. Сервер с установленным OMSA (см. ссылку выше)
2. Скачать и установить phantomjs (http://phantomjs.org/download.html)
3. Скачать и установить casperjs (http://docs.casperjs.org/en/latest/installation.html)
4. Вытащить утилиту из git:
git clone https://github.com/jazzl0ver/dell_raid_cc5. Создать файл с параметрами доступа (например, creds.txt):
export OMSAHOST=192.168.1.191
export OMSAPORT=1311
export USERNAME=root
export PASSWORD=password
export DELLHOST=192.168.1.306. Загрузить его и можно запускать утилиту или ставить ее запуск в кронтаб:
source creds.txt
casperjs --ignore-ssl-errors=true --cookies-file=/tmp/dell_raid_cc_cookie.jar dell_raid_cc.js
Если все в порядке, то вывод будет примерно такой:
Found: Virtual Disk 0 [state: Ready; layout: RAID-10; size: 1,862.00GB]
CC for Virtual Disk 0 has been started
Found: Virtual Disk 1 [state: Ready; layout: RAID-1; size: 931.00GB]
CC for Virtual Disk 1 has been started
Если запустить еще раз, можно увидеть прогресс проверки, например:
Found: Virtual Disk 0 [state: Resynching; layout: RAID-6; size: 5,026.50GB]
CC for Virtual Disk 0 is still running, progress: 19% complete
Стоит сказать, что утилита не поддерживает многоконтроллерные системы (у меня просто таких нет и протестировать, соответственно, не на чем).
Надеюсь, утилита окажется полезной не только мне.
UPD. Как подсказали коллеги в комментариях, более правильно настроить запуск проверки на целостность по расписанию с помощью утилиты megacli. Например:
./MegaCli -AdpCcSched -SetStartTime 20140822 04 -aALL
Инструкции по установке на сервер с CentOS/RedHat — здесь
Настройка расписания CC — здесь
Под ESXi также легко устанавливается. Можно поставить vib напрямую, либо сделать из него bundle и поставить в качестве обновления через vCenter.
UPD. #2 Контроллеры Perc5 не поддерживают настройку расписания через MegaCli:
cd /opt/lsi/MegaCLI; ./MegaCli -AdpCcSched -Info -aALL
Adapter 0: Scheduled Chceck Consistency is not supported.
Exit Code: 0x01
Для них использование dell_raid_cc — единственный способ автоматизации.
Комментарии (14)
merlin-vrn
21.03.2016 08:44+3Надеюсь, никто не будет делать это подобным вендоро-зависимым способом. Тем более, если учесть, что этот костыль вообще не нужен — функционал проверки встроен в сам контроллер.
Дело в том, что (актуальные версии) DELL PERC — это LSI MegaRaid SAS. И к нему отлично подходит стандартный MegaCLI. Поэтому, например, в Debian (то есть, заодно и в Proxmox VE, не говоря уже про всякие убунты) то, что вы сделали, решается так: подключаем репозиторий из http://hwraid.le-vert.net/ и ставим apt-get install megacli. А потом читаем мануалу от этой утилиты. Эта же самая утилита работает с как бы Intel-овскими контроллерами SRCSASRB.
От утилиты нам для начала всего-то надо настроить встроенный в RAID-контроллер Patrol Read — это автоматическое периодическое "патрулирование":
MegaCli -Dsbl|EnblAuto|EnblMan|Start|Suspend|Resume|Stop|Info|SSDPatrolReadEnbl |SSDPatrolReadDsbl |{SetDelay Val}|{-SetStartTime yyyymmdd hh}|{maxConcurrentPD Val} -aN|-a0,1,2|-aALL
Вот как это выглядит в моём случае (PERC H710 Adapter):
root@vh0:/home/merlin# megacli -adppr -info -a0 Adapter 0: Patrol Read Information: Patrol Read Mode: Auto Patrol Read Execution Delay: 168 hours Number of iterations completed: 121 Next start time: 03/26/2016, 14:00:00 Current State: Stopped Patrol Read on SSD Devices: Disabled Exit Code: 0x00
И если в процессе патрулирования на диске выявится проблема, контроллер выкинет его из RAID и включит Alarm. А если есть Hot Spare, то введёт его в строй.
После настройки утилиту удалять не спешите — мониторить и конфигурировать контроллер ею удобнее, чем с помощью iDRAC или не дай бог OMSA.
Во-вторых, берём smartmontools, который опять же — вуаля! — умеет получать диагностическую информацию с дисков "сквозь" контроллер.
Например:
root@vh0:/etc/zabbix# /usr/sbin/smartctl --all -d megaraid,8 /dev/sda smartctl 6.4 2014-10-07 r4002 [x86_64-linux-4.2.8-1-pve] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org /dev/sda [megaraid_disk_08] [SAT]: Device open changed type from 'megaraid,8' to 'sat+megaraid,8' === START OF INFORMATION SECTION === Model Family: Western Digital VelociRaptor Device Model: WDC WD1500HLFS-01G6U0 Serial Number: WD-xxxxxxxxxxxxx LU WWN Device Id: x xxxxxx xxxxxxxxx Firmware Version: 04.04V01 User Capacity: 150,039,945,216 bytes [150 GB] Sector Size: 512 bytes logical/physical Rotation Rate: 10000 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 2.5, 3.0 Gb/s Local Time is: Mon Mar 21 08:36:36 2016 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled ...
А несложный парсер, встроенный в Zabbix, извлекает интересные значения атрибутов из ответа smartctl и megacli и сообщает о проблемах.
jazzl0ver
21.03.2016 15:32+1Спасибо за развернутый ответ! Вы правы, мониторить через megacli более правильно. Дополнил статью.
Что касается, Patrol Read vs CC — если я правильно понял документацию, то одно другое не заменяет, а дополняет:
Patrol Read vs Consistency CheckDell hardware-based RAID controllers offer features such as Patrol Read and Check Consistency to correct many data error scenarios. Patrol Read operates by default as an automated background task that checks all of the individual blocks on a hard drive to ensure that the data can be read correctly. Patrol Read will attempt to correct blocks that are bad or remap un-correctable blocks to reserved blocks. Check Consistency is a manually activated (it can also be scheduled) function that compares all the drives in an array against each other to ensure that the data and redundancy correctly match. For example, three drives in a RAID 5 array will be compared to ensure that the data and the parity are using the correct values. If a single error is detected, the remaining data and/or parity will be used to re-write and correct the bad value. Similarly, in a RAID 1 array, the data on one drive will be compared to the other drive to ensure that the data is mirrored correctly. Dell recommends a Check Consistency is performed every 30 days to ensure that the array remains healthy.
merlin-vrn
21.03.2016 15:47+1Своё отношение к VMWare и в частности именно на сервере Dell я высказал в этом ответе: http://serverfault.com/questions/61644/can-you-use-a-usb-hard-drive-in-esxi/761852#761852
Короче говоря, в ней всё равно ничего не работает. Так что ну его нафиг. Возможно, это подходит для больших серверных ферм с отдельной SAN, отдельной сетью управления и так далее, но точно не для отдельно стоящих хостов виртуализации.
RicoX
У меня OMSA создала впечатление очень геморройной тулзы, не везде ставится, виснет, глючит, отказался от нее года 3 назад, может и допилили, но желания вернуться нет, для мониторинга рейдов использую свой костыль на megacli, который отдает параметры в zabbix, так и весь мониторинг в одном месте и сервера разных вендоров отлично видно, а не только Dell ну и многоконтроллерные системы отлично работают.
jazzl0ver
Не знаю, у меня с OMSA проблем не возникло. Под CentOS ставится буквально парой команд (http://linux.dell.com/repo/hardware/latest/ или http://linux.dell.com/repo/hardware/dsu/). После чего можно обновлять прошивки всех компонентов одной командой — удобно.
Что касается megacli — да, вы правы, спасибо за наводку! Я как-то в процессе поиска не подумал о таком варианте (хотя знал, что контроллеры в Dell'ах — LSI). Самое интересное, что техподдержка Dell, у которой я напрямую спрашивал, как удаленно включать CC, других вариантов, кроме omconfig/omreport, не предложила.
RicoX
Только пока сервер новый, к сожалению, через год-полтора если вывести сервер из продакшина и постараться обновить все компоненты начинают вылазить глюки, то сертификат просрочен, то путь сменился, то подпись, то формат прошивки и из автоматической операции "все и сразу одной кнопкой" превращается в рутину по ручному накатыванию разных компонентов в определенной последовательности. И это я про не древние R510 / R520 / R710 / R720 говорю, если попробовать провернуть этот фокус с какими-нибудь R210 или вообще 860, то танцы с бубном обеспечены. Идея изначально хорошая, но реализация — мрак.
Ну на CentOS мир операционок не заканчивается, на deb работает очень со скрипом, некоторые библиотеки приходится тащить в ручную, где то конвертировать rpm, сам по себе OMSA громоздкий и вендорлок.
На вкус и цвет понятно кому что нравится, но имея большой парк разновендорных серверов хочется видеть их все в одном месте на мониторинге, а не ходить по десятку вендорских решений.
jazzl0ver
У нас много R710 — на все OMSA встал без проблем и также без проблем обновляет прошивки. Также OMSA стоит на 1950, 2950 и R620. Скорее всего, тут дело именно в Debian. OMSA на офсайте есть только под RH/CentOS и OpenSUSE.
Но в целом, я с вами согласен: софт у Dell'а явно не его конек (от одного взгляда на OpenManage Essentials дурно становится).
merlin-vrn
У нас стоит OMSA в Debian. Для галочки, правда, стоит, так-то он там не используется. Потому, что не нужен :)
RicoX не помню больших проблем, ставилось по принципу "подключить репозиторий, поставить apt-get ом". Труднее всего было найти сам репозиторий (и то, что он "неофициальный", при том, что HP в аналогичном случае предлагает нормальный официальный).
RicoX
У меня тоже стоял, но зачем? Так то он запускается и даже морду страшную открывает, ту что на iDrac похожа, но при работе с прошивками сыплет ошибками часто и много, пробовали как-то с неделю, поигрались — удалили. Все вендор привязанные решения рождают в компании кучу геморроя, от обучения нового персонала до срочного расширения и поддержки функционала, нельзя просто так взять и добавить даже мелкую фишку. При наличии открытых более функциональных решений использовать это, как по мне мазахизм, если только не все железо одного вендора и куплена полная поддержка с хорошим SLA, чтоб не самому с этим трахаться.
jazzl0ver
JFYI: оказалось, что расписание через megacli доступно только для контроллеров Perc от 6-й версии и выше. Дополнил статью.