Контроль исправности сервера под управлением гипервизора VMware vSphere ESXi v5

  • Tutorial
Встала необходимость организовать мониторинг исправной работы контроллеров семейства LSI MegaRAID на серверах, работающих под управлением гипервизора VMware vSphere ESXi v5.5. И соответственно автоматически получать уведомления при наличии какого-либо сбоя, например отказе одного из HDD. В процессе проработки оказалось, что найденное решение не ограничивается только хранилищами данных гипервизора.

В моем распоряжении был тестовый сервер на базе материнской платы Supermicro X9DR3/i-F с контроллером LSI MegaRAID SAS 9260-4i, к которому было подключено два HDD и настроен RAID1.
Не смотря на то, что LSI MegaRAID SAS 9260-4i официально поддерживается в ESXi, зайдя в раздел «Health Status» клиента VMware vSphere, вы не сможете получить какой-либо информации о состоянии RAID:


К счастью, это поправимо. Отправляемся на сайт lsi.com и находим там архив со «SMIS Provider» для нужного контроллера:


Скачиваем, распаковываем и находим файл с расширением «vib». Это пакет, обеспечивающий мониторинг состояния контроллера с помощью встроенного механизма сенсоров ESXi. Копируем этот vib на сервер, подключаемся к нему по SSH и устанавливаем:
esxcli software vib install -v /vmfs/volumes/datastore1/500.04.V0.53-0003.vib


Перегружаем сервер, снова подключаемся к нему по SSH и удостоверяемся, что пакет установился:
esxcli software vib list | grep -i lsi


Теперь в разделе «Health Status» мы можем наблюдать состояние контроллера LSI MegaRAID:


Но, конечно, для автоматического мониторинга этого недостаточно. Поскольку мы не узнаем о сбое до тех пор, пока не запустим клиент VMware vSphere. Необходимо автоматизировать процедуру опроса сенсоров. Для этого используем скрипт «check_esxi_hardware.py», доступный на http://www.claudiokuenzler.com/nagios-plugins/check_esxi_hardware.php Изначально он является расширением для Nagios. Однако весьма универсален, и подключить его к любой другой системе мониторинга не составит особого труда.
Скрипт написан на языке программирования Python, требует библиотеку PyWBEM. Под ОС Linux Debian и Ubuntu она устанавливается через стандартные системные репозитории:
apt-get install python-pywbem

Синтаксис запуска «check_esxi_hardware.py» весьма прост:
check_esxi_hardware.py -H XXX.YYY.WWW.ZZZ -U root -P XXXXXXXX

В ответ вы получите краткий отчет о состоянии здоровья сервера:
OK - Server: Supermicro X9DR3-F s/n: 0123456789 System BIOS: 3.0a 2013-07-31

Убедиться в том, что скрипт опрашивает состояние всех сенсоров, в том числе контроллера LSI MegaRAID, можно, включив детальный вывод информации:
check_esxi_hardware.py -H XXX.YYY.WWW.ZZZ -U root -P XXXXXXXX -v


Недостатком скрипта является то, что для опроса сенсоров, ему необходимо предоставить авторизационные данные администратора гипервизора. Необязательно это может быть root, однако он должен обладать соответствующими правами, иначе опросить сенсоры не получится.
Попробуем сымитировать сбой одного из HDD. Перегружаем сервер и заходим в WebBIOS контроллера. Выбираем один из жестких дисков:


Заходим в его свойства:


И отключаем:


Загружаем гипервизор и в клиенте VMware vSphere видим, что действительно имеет место сбой:


А вот, что выдает «check_esxi_hardware.py»:
SIM-Networks
48.93
Professional hosting solutions — Hosted in Germany
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 15

    +2
    Гораздо интереснее выглядел бы скрипт для реализации autodiscover этих сенсоров для Zabbix, надо будет попробовать доработать.
    Но и отдельно тоже неплохо, спасибо!
      +1
      Если что-то получиться — просьба поделиться с общественностью.
      ===============
      Поскольку мы не узнаем о сбое до тех пор, пока не запустим клиент VMware vSphere.

      Можно просто активировать e-mail алерты. Помимо отображение в vCenter, будет еще и мыло слаться админам.
        0
        Есть пара вариантов:
        1. Zabbix Sender — при условии что vCenter на винде www.zabbix.com/forum/showthread.php?t=39391
        2. мониторинг ESXi хостов по SNMP и CIM провайдерам — могу написать статейку если надо (у нас в инфра-туре так и реализовано)
          0
          1) Используем vCSA
          2) Это оч интересно. Буду признателен за статейку.
            0
            Полный мониторинг по SNMP возможен вроде только в ESX, что касается ESXi, то не все вендоры возвращают значения сенсоров в SNMP от cim. Они умеют только слать trap`ы. Лично мне не сильно нравится с ними возится. Возможно, я ошибаюсь. Но в любом случае эта тема интересная.
            0
            Вы посмотрите скрипт. Там сенсоры делятся на инстансы, в которых потом банальным перебором определяются количество элементов и их состояния. Autodiscover, конечно, классно. Но смысл с этим заморачиваться, когда можно кинуть алерт, что какой-то из элементов в instance содержит ошибку. В вашем случае для zabbix хватит банальной функции check(instanceName), которая вернет вам ложь или истину, уже потом можно более детально посмотреть чем-нибудь еще.
          0
          Мда, а я для себя делаю вывод — хорошо, что «сижу» на HP — для их серверов у vmware есть HP Custom Iso, куда входят драйвера и все вот эти красоты с «system health» и плюс утилиты командной строки, мне нечасто, но бывает нужно использовать hpssacli. Хотя при желании и сноровке можно сделать свой собственный Custom ISO под любого вендора, в том числе — и под SuperMicro
            0
            Переписывал этот скрипт для системы мониторинга. Так вот во время работы выяснилось: без указания вендора в аргументах командной строки не всегда возвращаются верные значения в Element Op Status, это касается в первую очередь LSI контроллеров, при этом после смены состояния (допустим, вывалился хард) и устранения неполадки Element Op Status не возвращается на нормальное значение. Eсли это брендовое железо, то лучше использовать соответствующий флаг. Например, для HP скрипт будет возвращать Health State, а не Element Op Status, вот с ним проблем не замечено.
              0
              check_esxi_hardware.py -H XXX.YYY.WWW.ZZZ -U root -P XXXXXXXX -v


              Лучше не использовать root в таких вещах, ESXi позволяет сделать отдельную учетную запись с доступом к сенсорам.
                0
                В VMware vSphere ESXi v5.5 я пробовал создавать отдельную учетную запись и назначать ей роль «Read-only». Добавлял отдельную роль с привилегиями «Host.Config.SystemManagement» и «Host.CIM.CIMInteraction», как это рекомендуется в https://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.security.doc/GUID-645EBD81-CF86-44D7-BE77-224EF963D145.html Даже разрешал абсолютно все привилегии, т.е. фактически делал вновь созданную роль эквивалентной в своих правах встроенной «Administrator». Результат был один и тот же, при запуске скрипта «check_esxi_hardware.py»: «UNKNOWN: Authentication Error». Причиной этого является то, что PAM блокирует доступ к гипервизору через SSH и CIM всех, кому не назначена встроенная роль «Administrator»: https://communities.vmware.com/message/2319182#2319182 Единственное найденное мною решение этой проблемы – это ручная правка файла «/etc/security/access.conf» в гипервизоре: http://exchange.nagios.org/directory/Plugins/Operating-Systems/%2A-Virtual-Environments/VMWare/check_esxi_hardware-2Epy/details#rev-3055
                  0
                  Совершенно верно, тычку shell access до сих пор не исправили, поэтому пока только правка конфига, и не стоит забывать, что после ребута хоста все вернется в дефолтное состояние, поэтому эту процедуру исправления "-" на "+" надо добавить в автозапуск.
                    0
                    Все же это лучше, чем использовать root ;)
                      0
                      Добавлю, что не только ребут возвращает access.conf в дефолт, но и любые манипуляции с локальными пользователями. Поэтому лучше добавить cronjob, типа:
                      user=nagios; access=/etc/security/access.conf; crontab=/var/spool/cron/crontabs/root; grep $access $crontab > /dev/null || cat << EOF >> $crontab
                      */5  *    *   *   *   grep '^+:$user:sfcb$' $access > /dev/null || sed -i '2i +:$user:sfcb' $access
                      EOF
                      

                      (Взято отсюда)
                    0
                    Это баг в ESXi, который они, почему-то, не фиксят.
                    Work around: maximum-value.blogspot.com/2014/09/safe-work-around-to-make.html
                    0
                    Сделал подобный финт для DELL PERC H200
                    Судя по гуглу внутри там LSI MegaRAID SAS 9240-4i
                    На 5.5.0 1623387 был установлен 00-57-V0-03_SMIS_VMware_Provider от LSI и после перезагрузки хоста latency выросла на порядки как для САТА так и для ССД дисков.

                    ЧЯДНТ ??

                    Only users with full accounts can post comments. Log in, please.