Как стать автором
Обновить

Комментарии 14

У меня OMSA создала впечатление очень геморройной тулзы, не везде ставится, виснет, глючит, отказался от нее года 3 назад, может и допилили, но желания вернуться нет, для мониторинга рейдов использую свой костыль на megacli, который отдает параметры в zabbix, так и весь мониторинг в одном месте и сервера разных вендоров отлично видно, а не только Dell ну и многоконтроллерные системы отлично работают.
Не знаю, у меня с OMSA проблем не возникло. Под CentOS ставится буквально парой команд (http://linux.dell.com/repo/hardware/latest/ или http://linux.dell.com/repo/hardware/dsu/). После чего можно обновлять прошивки всех компонентов одной командой — удобно.

Что касается megacli — да, вы правы, спасибо за наводку! Я как-то в процессе поиска не подумал о таком варианте (хотя знал, что контроллеры в Dell'ах — LSI). Самое интересное, что техподдержка Dell, у которой я напрямую спрашивал, как удаленно включать CC, других вариантов, кроме omconfig/omreport, не предложила.
После чего можно обновлять прошивки всех компонентов одной командой — удобно.

Только пока сервер новый, к сожалению, через год-полтора если вывести сервер из продакшина и постараться обновить все компоненты начинают вылазить глюки, то сертификат просрочен, то путь сменился, то подпись, то формат прошивки и из автоматической операции "все и сразу одной кнопкой" превращается в рутину по ручному накатыванию разных компонентов в определенной последовательности. И это я про не древние R510 / R520 / R710 / R720 говорю, если попробовать провернуть этот фокус с какими-нибудь R210 или вообще 860, то танцы с бубном обеспечены. Идея изначально хорошая, но реализация — мрак.

Под CentOS ставится буквально парой команд

Ну на CentOS мир операционок не заканчивается, на deb работает очень со скрипом, некоторые библиотеки приходится тащить в ручную, где то конвертировать rpm, сам по себе OMSA громоздкий и вендорлок.
На вкус и цвет понятно кому что нравится, но имея большой парк разновендорных серверов хочется видеть их все в одном месте на мониторинге, а не ходить по десятку вендорских решений.
У нас много R710 — на все OMSA встал без проблем и также без проблем обновляет прошивки. Также OMSA стоит на 1950, 2950 и R620. Скорее всего, тут дело именно в Debian. OMSA на офсайте есть только под RH/CentOS и OpenSUSE.

Но в целом, я с вами согласен: софт у Dell'а явно не его конек (от одного взгляда на OpenManage Essentials дурно становится).
У нас стоит OMSA в Debian. Для галочки, правда, стоит, так-то он там не используется. Потому, что не нужен :)


RicoX не помню больших проблем, ставилось по принципу "подключить репозиторий, поставить apt-get ом". Труднее всего было найти сам репозиторий (и то, что он "неофициальный", при том, что HP в аналогичном случае предлагает нормальный официальный).
У меня тоже стоял, но зачем? Так то он запускается и даже морду страшную открывает, ту что на iDrac похожа, но при работе с прошивками сыплет ошибками часто и много, пробовали как-то с неделю, поигрались — удалили. Все вендор привязанные решения рождают в компании кучу геморроя, от обучения нового персонала до срочного расширения и поддержки функционала, нельзя просто так взять и добавить даже мелкую фишку. При наличии открытых более функциональных решений использовать это, как по мне мазахизм, если только не все железо одного вендора и куплена полная поддержка с хорошим SLA, чтоб не самому с этим трахаться.
JFYI: оказалось, что расписание через megacli доступно только для контроллеров Perc от 6-й версии и выше. Дополнил статью.
Надеюсь, никто не будет делать это подобным вендоро-зависимым способом. Тем более, если учесть, что этот костыль вообще не нужен — функционал проверки встроен в сам контроллер.

Дело в том, что (актуальные версии) 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 и сообщает о проблемах.
Спасибо за развернутый ответ! Вы правы, мониторить через megacli более правильно. Дополнил статью.
Что касается, Patrol Read vs CC — если я правильно понял документацию, то одно другое не заменяет, а дополняет:

Patrol Read vs Consistency Check
Dell 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.


Также обращу внимание, что Patrol Read на контроллерах включен по-умолчанию, но предотвратить описанный случай не смог. Так что я бы все-таки не стал отказываться от периодических CC.

FYI: smart на ESXi никакой информации не дает:

# /usr/lib/vmware/vm-support/bin/smartinfo.sh
SMART Information for disks.

Device:  naa.60026b906129bc001da8ed9b0801133c
Parameter                     Value  Threshold  Worst
-----------------------------------------------------
Health Status                 N/A    N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              N/A    N/A        N/A
Power-on Hours                N/A    N/A        N/A
Power Cycle Count             N/A    N/A        N/A
Reallocated Sector Count      N/A    N/A        N/A
Raw Read Error Rate           N/A    N/A        N/A
Drive Temperature             N/A    N/A        N/A
Driver Rated Max Temperature  N/A    N/A        N/A
Write Sectors TOT Count       N/A    N/A        N/A
Read Sectors TOT Count        N/A    N/A        N/A
Initial Bad Block Count       N/A    N/A        N/A
Своё отношение к VMWare и в частности именно на сервере Dell я высказал в этом ответе: http://serverfault.com/questions/61644/can-you-use-a-usb-hard-drive-in-esxi/761852#761852


Короче говоря, в ней всё равно ничего не работает. Так что ну его нафиг. Возможно, это подходит для больших серверных ферм с отдельной SAN, отдельной сетью управления и так далее, но точно не для отдельно стоящих хостов виртуализации.
ZFS смотрит на Ваши проблемы, тихо похихивая — она-то умеет распознавать и бесперебойно восстанавливать "выпавшие" диски.
Все, кто может отличить софт-рейд в любой его реализации от железного массива, смотрят на Вас громко хихикая.
Ну вот и сидите на своём железном массиве с битыми данными, а мой софт-ZFS уже раз пять вытаскивал меня из таких ситуаций, в которых ни одна железяка не выдержала бы — например, когда винты из обеих половины зеркала оказались частично битыми.
Ну вот и сидите на своем ZFS, безуспешно пытаясь впихнуть на него ESXi. А вы не думали, что у каждой реализации должна быть своя ниша? Прекрасно уживаются одновременно и софт-рейды и "настоящие", просто у них разные задачи.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории