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

[blind_oracle]

Гораздо интереснее выглядел бы скрипт для реализации autodiscover этих сенсоров для Zabbix, надо будет попробовать доработать.
Но и отдельно тоже неплохо, спасибо!

[m0ps]

Если что-то получиться — просьба поделиться с общественностью.
===============

Поскольку мы не узнаем о сбое до тех пор, пока не запустим клиент VMware vSphere.

Можно просто активировать e-mail алерты. Помимо отображение в vCenter, будет еще и мыло слаться админам.

[Mephistos]

Есть пара вариантов:
1. Zabbix Sender — при условии что vCenter на винде www.zabbix.com/forum/showthread.php?t=39391
2. мониторинг ESXi хостов по SNMP и CIM провайдерам — могу написать статейку если надо (у нас в инфра-туре так и реализовано)

[m0ps]

1) Используем vCSA
2) Это оч интересно. Буду признателен за статейку.

[ol_x]

Полный мониторинг по SNMP возможен вроде только в ESX, что касается ESXi, то не все вендоры возвращают значения сенсоров в SNMP от cim. Они умеют только слать trap`ы. Лично мне не сильно нравится с ними возится. Возможно, я ошибаюсь. Но в любом случае эта тема интересная.

[ol_x]

Вы посмотрите скрипт. Там сенсоры делятся на инстансы, в которых потом банальным перебором определяются количество элементов и их состояния. Autodiscover, конечно, классно. Но смысл с этим заморачиваться, когда можно кинуть алерт, что какой-то из элементов в instance содержит ошибку. В вашем случае для zabbix хватит банальной функции check(instanceName), которая вернет вам ложь или истину, уже потом можно более детально посмотреть чем-нибудь еще.

[nickolazz]

Мда, а я для себя делаю вывод — хорошо, что «сижу» на HP — для их серверов у vmware есть HP Custom Iso, куда входят драйвера и все вот эти красоты с «system health» и плюс утилиты командной строки, мне нечасто, но бывает нужно использовать hpssacli. Хотя при желании и сноровке можно сделать свой собственный Custom ISO под любого вендора, в том числе — и под SuperMicro

[ol_x]

Переписывал этот скрипт для системы мониторинга. Так вот во время работы выяснилось: без указания вендора в аргументах командной строки не всегда возвращаются верные значения в Element Op Status, это касается в первую очередь LSI контроллеров, при этом после смены состояния (допустим, вывалился хард) и устранения неполадки Element Op Status не возвращается на нормальное значение. Eсли это брендовое железо, то лучше использовать соответствующий флаг. Например, для HP скрипт будет возвращать Health State, а не Element Op Status, вот с ним проблем не замечено.

[ol_x]

check_esxi_hardware.py -H XXX.YYY.WWW.ZZZ -U root -P XXXXXXXX -v

Лучше не использовать root в таких вещах, ESXi позволяет сделать отдельную учетную запись с доступом к сенсорам.

[simnetworks]

В 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

[ol_x]

Совершенно верно, тычку shell access до сих пор не исправили, поэтому пока только правка конфига, и не стоит забывать, что после ребута хоста все вернется в дефолтное состояние, поэтому эту процедуру исправления "-" на "+" надо добавить в автозапуск.

[ol_x]

Все же это лучше, чем использовать root ;)

[jazzl0ver]

Добавлю, что не только ребут возвращает 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

(Взято отсюда)

[giner]

Это баг в ESXi, который они, почему-то, не фиксят.
Work around: maximum-value.blogspot.com/2014/09/safe-work-around-to-make.html

[Fanta]

Сделал подобный финт для DELL PERC H200
Судя по гуглу внутри там LSI MegaRAID SAS 9240-4i
На 5.5.0 1623387 был установлен 00-57-V0-03_SMIS_VMware_Provider от LSI и после перезагрузки хоста latency выросла на порядки как для САТА так и для ССД дисков.

ЧЯДНТ ??