Особенности мониторинга ресурсов виртуальных машин в VMware vSphere

В прошлый раз я писал о том, как настроить виртуальные машины, работающие в среде VMware Workstation, для обеспечения их максимальной производительности. Сегодня же хотел поговорить про решения Enterprise уровня от компании VMware. А в частности про мониторинг использования ресурсов виртуальных машин в VMware vSphere.

Если кто-то не сильно разбирается в маркетинговых названиях, поясню. У компании VMware есть гипервизор, который устанавливается на физическую машину, называется он - VMware ESXi. Для управления и мониторинга у ESXi имеется встроенная графическая web-консоль. Но, если виртуализированных хостов в дата-центре много, то управлять этим хозяйством становится сложнее. Так как для мониторинга или изменения конфигурации гипервизоров необходимо входить на web-консоль каждого ESXi. Для упрощения данной задачи (конечно, за отдельные деньги) компания предлагает решение VMware vCenter. В этом случае выделенный виртуальный сервер  предоставляет единую точку входа для мониторинга, управления и конфигурации ESXi хостов вашей организации. Помимо общей точки входа вы получаете дополнительные функции, например, vMotion (перенос работающих виртуальных машин между ESXi хостами) или HA кластер. Комплексное решение "ESXi + vCenter" и называется VMware vSphere. Достаточно подробно про эти решения я рассказывал в этом посте. 

Раз с названиями разобрались, двигаемся дальше, ближе к теме сегодняшнего поста. 

На хосте под управлением гипервизора ESXi работают виртуальные машины. Мониторинг ресурсов сервера (процессор, память, сеть и т.д.) в случае виртуализации рекомендуется выполнять не на уровне операционной системы виртуальной машины, а (если вам это доступно) на уровне гипервизора VMware.

Web-консоль VMware ESXi позволяет выполнять мониторинг виртуальных машин лишь в реальном времени: статистика по загрузке процессоров, памяти, дисков и сети собирается и хранится только за последний час (рис. 1).

Рис. 1. Пример панели мониторинга процессора виртуальной машины в ESXi.

Согласитесь, что для промышленных систем это несерьёзно. Мониторинга фактически нет. Можно отметить, что на уровне операционной системы ESXi сервера (помните, что в основе это Linux) есть утилита esxtop (я упоминал про неё тут), но она тоже показывает только текущую нагрузку в системе. 

В свою очередь VMware vCenter имеет гораздо больше возможностей по мониторингу. В его консоли отображается не только текущая картина потребления ресурсов, но и собирается база статистики за прошедшие периоды. Можно выбрать различные метрики: процессорные ресурсы (загрузка в % или в MHz), оперативная память, swap-область, дисковая подсистема (несколько метрик), сеть и так далее. Данные для каждой метрики можно выбрать из стандартного набора интервалов:

• real-time,
• last day,
• last week,
• last month,
• last year,
• или задать свой интервал через custom interval.

Режим отображения real-time похож на то, что можно найти в консоли ESXi и обладает самой высокой точностью данных. Достигается это за счёт частоты сбора. Мне кажется, данные собираются раз в секунд 15-30. А вот дальше есть интересный нюанс, ради которого я и начал писать этот пост. Все остальные интервалы отображают менее детализированные данные, так как vCenter автоматически выполняет агрегацию данных. Если войти в раздел "Configure -> Settings -> General" вашего виртуального Datacenter, то можно увидеть параметры для сбора статистики. Значения по умолчанию выглядят так (рис. 2).

Рис. 2. Настройки сбора и агрегации статистики производительности.

Обратите внимание, что для статистики сохранённой за последний день (last day) данные собираются раз в 5 минут, для последней недели (last week) раз в 30 минут, для месяца (last month) раз в 2 часа, а для года (last year) раз в день. Вы можете попробовать поменять настройки, но обнаружите, что самые глубокие доступные значения параметров для хранения статистики выглядят так (рис. 3).

Рис. 3. Максимально глубокие значения для хранимой статистики.

Подкрутить можно только первый уровень: для последних 5 дней хранить данные с частотой 1 минута. Глубину данных за более длительные периоды изменить нельзя. 

Кстати, хочу обратить внимание, что при изменении этих настроек VMware дополнительно рассчитывает требования к дисковому пространству для хранения статистики (рис. 3). Причём, вы можете подкорректировать количество хостов и виртуальных машин в вашем Datacenter для отображения более реальных значений для текущей инфраструктуры. 

Снижение глубины статистики для прошедших периодов было бы не такой большой бедой, если бы не логика работы vCenter в этой части. Снижая частоту хранимых исторических данных, он не просто отбрасывает лишние значения, а автоматически агрегирует данные, усредняя значения. То есть для статистики, хранимой за последнюю неделю, берётся среднее значение с параметров за каждый 30 минутный интервал. А для интервалов старше недели, вообще за каждые 2 часа. Такая логика работы, как я понял, жёстко зашита в vCenter и приводит к сглаживанию показателей нагрузки в зависимости от запрашиваемого интервала. 

Давайте я продемонстрирую это наглядно на одной из систем. Рассмотрим статистику по загрузке процессора виртуальной машины последовательно за разные периоды (рис. 4 - 8).

Рис. 4. Просмотр статистики загрузки CPU в реальном времени.

Рис. 5. Просмотр статистики загрузки CPU за последние сутки.

Рис. 6. Просмотр статистики загрузки CPU за последнюю неделю.

Рис. 7. Просмотр статистики загрузки CPU за последний месяц.

Рис. 8. Просмотр статистики загрузки CPU за год.

Замечаете как показатели утилизации процессора из 50-75% постепенно превращаются в 40-60%, потом опускаются ниже 50%, а в годовом разрезе вообще не поднимаются выше 15%? :) 

Рассмотрим ещё один пример. График загрузки процессора виртуальной машины за неделю показывает пиковые значения не выше 60%, и то только один раз. В остальные дни не выше 50%. Можно сделать преждевременные выводы, что процессорных ресурсов данной системе хватает.

Рис. 9. Пример статистики загрузки процессора виртуальной машины за неделю.

А при этом на интервалах real-time для данной виртуальной машины фиксировались пики до 100% (рис. 10-12).

Рис. 10. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 11. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 12. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Если же обратиться к статистике за месяц, то опять видим ту же картину: пики едва превышают 40%. Сравните последние дни на разных графиках, где мы точно знаем, что были значения и по 100%. На графике с большим периодом отображения таких значений просто нет: они сглажены агрегацией (рис. 13). 

Рис. 13. Пример статистики загрузки процессора виртуальной машины за месяц.

Какие выводы из всего этого можно сделать? 

Во-первых, нужно учитывать эту особенность сбора и отображения статистики по загрузке ресурсов виртуальной машины в VMware. Годовой график смотреть смысла нет, статистика гораздо ниже реальной. И даже в помесячном разрезе сглаженный график ниже реального где-то на 50%. 

Во-вторых, периодически смотрите график в реальном времени, сравнивая его значения с недельной или месячной статистикой. Только в этом разрезе можно увидеть реальные значения нагрузки на систему. 

Для некоторых приложений могут быть критичны, например, процессорные ресурсы сервера. И при их нехватке (достижении утилизации в 100%), даже на короткий период, происходят события в виде отказа в обслуживании или резкого снижения производительности приложений. 

Виртуализация позволяет оптимизировать утилизацию ваших ресурсов за счёт размещения на одном физическом сервере нескольких виртуальных серверов. Но при проектировании виртуальных машин мы должны обеспечить достаточность процессорных ресурсов. Мы же используем виртуализацию для оптимизации, полагая что процессорные ресурсы в полном объёме физического сервера приложениям в этой виртуальной машине не нужны. А, если приложения утилизируют все ресурсы виртуальной машины, упираясь в ограничения, наложенные гипервизором, то значит ресурсы были распределены некорректно. Или за время в пути собачка могла подрасти. 

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

В отслеживании пиков в потреблении процессорных ресурсов может помочь настройка Alarms в vCenter. По умолчанию существует Alarm с именем "Virtual machine CPU usage", который срабатывает при потреблении больше 75% процессорных ресурсов в течении 5 минут (рис. 14).

Рис. 14. Настройки Alarm "Virtual machine CPU usage".

Возникновение этих событий для виртуальной машины в прошлом можно найти в разделе Events (рис. 15).

Рис. 15. История возникновения событий превышения утилизации процессора виртуальной машиной.

Так вы по крайней мере сможете оценить в какие моменты и как часто не хватает процессорных ресурсов вашей виртуальной машине. Можно создать свой Alarm по аналогии с существующим, подкорректировав пороги срабатывания. 

Все эти рассуждения справедливы так же для распределения и мониторинга других ресурсов виртуальных машин: оперативной памяти, сети, дисков.

Автор: Шиболов Вячеслав Анатольевич