Как описать требования к производительности VMware для нашего приложения администратору VMware?

Зачастую установка нашего локального приложения на основе debian-stable выполняется на виртуальной машине - обычно в VMware ESXi. В общем случае мы не видим и не влияем на их среду виртуализации и не имеем доступа, например, к клиенту VMware vCenter или его аналогам. Я сосредотачиваюсь на VMware здесь, потому что это, безусловно, является наиболее распространенным, что мы видим.

Мы хотели бы:

• Сообщите администратору VMware клиента: вы можете запускать наше приложение, например, в вашей среде VMware ESX, если оно соответствует критериям производительности X, Y и Z.
• Уметь определять, выполняются ли критерии X, Y и Z на самом деле непрерывно (например, прямо сейчас ), даже в работающей системе (мы не можем остановить наше приложение и выполнить тесты, а начальный тест не будет достаточным, поскольку производительность в виртуальные среды меняются со временем).
• Будьте уверены, что если критерии X, Y и Z будут выполнены, у нас будет достаточно виртуальных ресурсов HW для запуска нашего приложения с удовлетворительной производительностью.

Теперь, что такое X, Y и Z?

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

Теоретически также возможно, что иногда наше приложение работает медленно ... ;-)

Как определить основную причину наших проблем с производительностью: виртуальная среда или наше приложение?

Обычно есть 3 области для проблем производительности CPU, Memory и DISK I / O.

Процессор

Например, в VMware администратор может указать Reservation and Limit, выраженный в МГц, но, например, 512 МГц на одном хосте ESX точно такой же, как 512 МГц на другом хосте ESX, возможно, в совершенно другом кластере ESX?

И как можно измерить, получаем ли мы это на самом деле? В то время как наше приложение работает, мы можем видеть, что мы используем 212% ЦП на 4 ЦП. Это потому, что наше приложение много работает или потому, что другая виртуальная машина на том же хосте выполняет задачу с интенсивным использованием ЦП и использует весь ЦП?

Память (раздувать?)

Если мы запрашиваем, например, 16 ГБ ОЗУ, это часто настраивается, но из-за раздувания мы фактически получаем только 4 ГБ, и, как ни удивительно, наше приложение работает плохо.

Можно спросить инструменты VMware о текущем всплывающем окне, но мы обнаружили, что оно часто ложное (или, по крайней мере, неточное). Мы видели примеры, когда ОС считает, что общее ОЗУ 16 ГБ, сумма резидентной памяти (RSS) всех процессов составляет 4 ГБ ОЗУ, но только 2 ГБ ОЗУ свободно, даже когда инструменты VMware сообщают нам, что всплывающее окно равно 0: - (

Кроме того, простое добавление RSS вместе недопустимо, поскольку там легко может быть общая оперативная память, например, память для копирования при записи, поэтому 512 МБ + 512 МБ не обязательно означают 1 ГБ, но могут означать нечто меньшее. Таким образом, нельзя просто вычесть RSS из всех процессов, чтобы определить, сколько оперативной памяти должно быть свободно, и, таким образом, надежно обнаруживать всплывающие подсказки. Можно обнаружить некоторые случаи раздувания, но есть другие случаи, когда раздувание действует, но не обнаруживается этим методом.

Дисковый ввод / вывод

Я предполагаю, что мы могли бы со временем отобразить число операций чтения и записи на диске, количество прочитанных и записанных байтов и% ожидания ввода-вывода. Но даст ли это нам точную картину дискового ввода-вывода? Я полагаю, что если на другой виртуальной машине запущен биткойн-майнер, использующий весь ЦП, наш процент ожидания ввода-вывода увеличится, даже если базовая сеть хранения данных дает точно такую ​​же производительность, просто потому, что ресурсы нашего ЦП снижаются, и, следовательно, ожидание ввода-вывода ( который измеряется в% ) идет вверх.

Итак, в заключение, какой язык мы можем использовать, например, для описания администратора VMware, какую производительность нам нужно, портативным и измеримым способом?

• Серьезно, большинство администраторов VMware не очень хороши в этом: плохое понимание управления ресурсами, часто отсутствие знаний о Linux (это помогает) и недостаток пропускной способности. Я считаю, что большинству внутренних администраторов трудно поддерживать глубокие знания виртуализации.

• К счастью, есть книга, которую вы можете прочитать !

• Большинство сред VMware не слишком хороши: плохой дизайн кластера, плохое планирование ресурсов , нестандартное хранилище (например, Synology NAS), неправильно настроенная HA, отсутствие мониторинга или исправлений.

• VMware как организация подводит нас: они особенно плохо распространяют актуальную информацию и пропагандируют лучшие практики. Обычный поиск общих вопросов дает результаты 2009 и более ранних версий VMware, несмотря на то, что процессы и конструкции менялись со временем.

Все эти вещи будут работать против вас.

Вы должны определить реальные требования вашего решения. Возможность точно указать, что вашему устройству требуются: производительность 2 vCPU, 8 ГБ ОЗУ и 500 IOP, будет иметь большое значение для таких, как я.

Другой подход состоит в том, чтобы наблюдать за здоровой или идеальной средой и экстраполировать метрики оттуда.

Вы описали проблемы с определенными развертываниями. Какие были проблемы и узкие места?

Пример виртуальной машины правильного размера:

Сервер Exchange для организации из 300 пользователей.

• У нас есть 6 недель тепловых карт нагрузки / стресса в зависимости от времени.
• 6 виртуальных ЦП удерживают нас над зоной стресса с буферной комнатой для пиков.
• 32 ГБ ОЗУ удерживает нас выше значения стресса, но не является чрезмерно большим количеством того, что действительно необходимо.

• Я мог бы вернуть несколько ГБ оперативной памяти и виртуальный процессор, но в целом это эффективная виртуальная машина.
• Было бы целесообразно получить этот тип мониторинга вашего приложения в идеальных условиях.

Примеры мониторинга ресурсов ВМ.

Хорошо: - ВМ правильного размера. - ЦП перегружен во всем кластере, но мы не сталкиваемся с конфликтом.

Bad-иш:

• Виртуальная машина никогда не получит всю оперативную память, с которой она настроена.
• ВМ уже подменяет оперативную память.
• Процессор переконфигурирован.