Система мониторинга выделенных ресурсов изнутри виртуальной машины

Question

[NetBear]

Приветствую.

Мы разрабатываем некую аппликацию реального времени, которая будет работать на виртуальной платформе. На сегодняшний день речь идёт о VMWare ESXi, хотя я бы не исключал вариантов развития в сторону KVM или Xen или даже поддержки мултиплатформенности.
Наше программное решение крайне чувствительно к нехватке системных ресурсов, в особенности мощности процессора и ширины канала сети. Нам необходимо разработать некую систему контроля за выделенными ресурсами, т.е. процесс, который изнутри виртуальной машины сможет отслеживать состояние системных ресурсов, собирать статистику и в случае необходимости посылать предупреждение. Основная проблема на данном этапе заключается в том, что система мониторинга сама находится внутри контейнера виртуальной машины. Собирать подобную статистику и производить мониторинг ресурсов с уровня host (hypervisor) не представляет проблемы, однако когда речь заходит о выполнение подобной задачи с уровня Guest OS начинаются сложности. Например, в данном случае отсутствует доступ к API самого VMWare ESXi.
Может быть кто-то из уважаемых членов сообщества сталкивался с подобными задачами или имеет теоретическое представление о том как можно реализовать подобную систему.

Заранее премного благодарен.

Answer 1

[Пума Тайланд]

Любой забикс, cacti, nagios.
Сбор статистики по сети, свои агенты на машинах + snmp.

Answer 2

[antivir]

Не очень пониманию, в чем проблема доступа из гостевой OS к API ESXi. Есть например, Veeam Backup and Replication, который прекрасно это делает. На крайний случай — свои агенты на хостах.

Answer 3

[NetBear]

Спасибо за ответы.
Проблема как раз именно в том, что я могу посадить агентов только внутрь гостевой ОС. У меня нет возможности измерять ресурсы на уровне хоста, моя система мониторинга инсталируется вместе с моей основной аппликацией. Ровно по той же самой причине мне не помогают решения из серии Cacti и Zabbix, т.к. они могут отслеживать активность внутри самого контейнера гостевой ОС с соответствующими ограничениями. Например, мы поставили нашу систему заказчику, прописали чёткие требования к ресурсам виртуальной машины, а у него наша аппликация бежит на сервере параллельно с ещё 20-ю виртуалками и политика resource sharing настроена, скажем так, не совсем верно. В какой-то момент времени на соседних виртуальных машинах в пиковом режиме повышается активность, что приводит к нехватке ресурсов для моего програмного решения. Изнутри контейнера моей виртуальной машины я по-прежнему вижу выделенные мне системные ресурсы и они по-прежнему в порядке, а на деле мне не хватает вычислительной мощности и проходимости сетевого канала, т.е. моя программа «задыхается». Если в такой момент произвести мониторинг ресурсов со стороны хоста, то мы увидим реальное положение вещей

Comments

[antivir]

По какой причине вам не подходит вот это?

[NetBear]

Это простое и элегантное решение само по себе, за исключением нескольких «но»:
1. Как сказанно в статье по присланной вами ссылке, ESXi SNMP stack поддерживает исключительно SNMP Trap метод. Т.е. система после конфигурации будет присылать вам некоторый предусмотренный инженерами VMWare набор alarms, при абсолютном отсутствии возможности кастомизации.
2. Я не могу предъявлять клиенту требование к специальной конфигурации hypervisor, т.к. на этом же сервере у него бегут ещё 20 машин.
3. В моём случае это решение абсолютно бесполезно, т.к. у VMWare SNMP stack отсутствует поддержка GET-methods, т.е. я не смогу запрашивать значение параметров хоста.
4. Я не уверен, но меня одолевают некоторые сомнения на счёт возможности SNMP доступа изнутри гостевой ОС к конфигурации хоста. ИМХО, это выглядит как грубейшее нарушение парадигмы изолированных виртуальных контейнеров.

[antivir]

Вы уже выработали нужные вам конкретные критерии системных ресурсов? Это что, конкретные гигагерцы в конкретный момент времени? Ну, придет предупреждение, а дальше что? Вы предложите заказчику принять меры, чтобы он настроил low limits и т.п.?

Что касается SNMP, то он работает по IP, и нет никаких проблем настроить маршрутизацию так, чтобы увидеть консольный адрес хоста из гостевой OS.

[NetBear]

Да, у нас будут чётко прописанные требования к конфигурации виртуальной машины под нашу конкретную аппликацию, не ниже «конкретных гигагерцев в любой момент времени». Придёт предупреждение это, в некотором смысле, половинчатое решение, нам нужно, чтобы данные писались в нередактируемый лог-файл. На случай сбоя нашей системы у нас на руках будет неопровержимое техническое доказательство того, что сбой произошёл по вине второй стороны и мы дадим свои рекоммендации по устранению неисправности.
Насчёт возможности настройки маршрутизации возможно Вы и правы, попробую на досуге. Ранее, я высказал некоторую догадку на уровне интуиции, у меня нет проверенных данных.

[antivir]

Подумайте об установке Veeam Monitor. Может имеет смысл договориться об этом с заказчиком. Кстати, по-моему, он получает данные из vCenter без установки агентов. Попробуйте узнать, как он это делает.
Вообще, из гостевой OS возможен точно такой же доступ ко всем ресурсам, как и из физического узла. Не вижу причин, по которым вы не можете использовать API хоста из гостевой OS.

Answer 4

[antivir]

Кстати, процессор можно зарезервировать в ресурспулах, есть еще traffic shaping (правда, сам его не пробовал).

Comments

[NetBear]

Да, вы совершенно правы. Всё это можно сделать. Можно поставить low limits на все критичные для нашей аппликации ресурсы, но… весь цимес системы мониторинга как раз в следующем. Если параметры виртуальной машины или resource sharing policy сконфигурированны некорректно и как результат система дала сбой. Заказчик делает брови домиком и приходит к вам с притензией, мол криво написали / плохо протестировали. В ответ на притензию мы просим прислать логи системы мониторинга, с помощью которых и доказываем, что проблема не в нашей реализации а в их конфигурации. Ну где-то так :)

Answer 5

[antivir]

Еще. Попробуйте проконсультироваться с М. Михеевым.