Мы используем приложение с примерно 300 одновременными пользователями. Теперь все виртуализировано: 1 VM как балансировщик нагрузки, 2 VM как веб-сервер (на этом хосте ESXi есть еще +25 других VM) и 1 сервер (голое железо) как SQL Server. У нас возникли некоторые проблемы с производительностью, и мы решили купить физическое оборудование, чтобы ее повысить.
Я не уверен, как мы можем улучшить производительность?:
мы покупаем 1 стоечное серверное оборудование и запускаем ESXi только со всеми 3 виртуальными машинами, указанными выше,
мы покупаем 1-1 стоечное серверное оборудование для веб-серверов и устанавливаем сервер Windows только с приложением. (и оставляем балансировщик нагрузки как прежде - VM)
- мы покупаем 3 стоечных сервера для балансировщика нагрузки и 2 веб-сервера.
Пользователи подключаются к серверу через веб-интерфейс/настольное приложение.
Спасибо за помощь, Дрюдо.
решение1
Прежде чем принять решение о дальнейшем пути, вам следует найти ответы на следующие вопросы:
Использование ЦП для затронутых виртуальных машин
- С точки зрения гостевой операционной системы, часто ли загрузка ЦП превышает 80% и/или показывает плато, а не пики в использовании? Вероятно, вашей виртуальной машине не хватает ЦП. Добавьте больше vCPU (но подумайте о возможных проблемах с лицензированием).
- Некоторые vCPU на ваших серверах загружены значительно меньше других? У вас может быть проблема масштабирования в вашем приложении, когда простое добавление большего количества vCPU в одну виртуальную машину (или в физическую машину) не решит проблему.
- Означает ли
CPU readyвремя, что хост перегружен? Эмпирическое правило, которое вы иногда видите, заключается в том, что вам нужно менее 5% среднего времени готовности, но мой опыт показывает, что даже это слишком много для системы, в которой вы фактически работаете. Обратите внимание, что если вы используете vCenter, указанное время готовности указывается в совокупных миллисекундах с момента последнего обновления графика. В режиме «реального времени» график обновляется каждые 20 секунд (=20000 мс), поэтому средний процент на ЦП для виртуальной машины можно рассчитать с помощью формулы(indicated_ready_time * 100 / 20000) / number_of_vcpu.
Использование оперативной памяти
(Всегда следует проверять из гостевой операционной системы)
- Обычно выше 80%? Добавьте памяти.
- Признаки утечки памяти? Исправьте приложение или будьте готовы перезапускать/перезагружать его чаще.
- Признаки интенсивной подкачки? Проверьте наличие проблем с конфигурацией. Добавьте памяти.
- У вас есть ключевые приложения/процессы, которые «необъяснимым образом» используют менее 4 ГБ памяти? Возможно, их нужно перестроить или перенастроить для использования 64-битной адресации.
Также проверьте производительность диска и сети на предмет задержек.
В зависимости от масштабируемости вашего приложения может возникнуть идея добавить больше веб-серверов, а не увеличивать вычислительную мощность или память уже существующих.
Как только вы поймете, где у вас узкие места и как лучше всего использовать ваше оборудование, вы сможете приступить к составлению экономического обоснования того, что именно следует приобрести.
Главным аргументом в пользу виртуальных машин является то, что ими легче управлять, их легче резервировать и легче переносить в случае сбоя системы. Они позволяют лучше использовать ваше оборудование, при условии, что они на самом деле не требуют всех ресурсов, которые вы можете им предоставить, и если вы используете паравиртуализированные сетевые интерфейсы, связь между машинами на одном хосте будет настолько быстрой, насколько может справиться ЦП, а не будет ограничена физическими скоростями сетевого интерфейса.
Система, работающая непосредственно на физической машине, конечно, не будет иметь накладных расходов из-за совместного использования ресурсов, но это преимущество только в том случае, если вы можете использовать имеющуюся мощность.
решение2
Без изучения причины проблем с производительностью и знания особенностей вашего приложения вы не сможете сказать, какой способ исправления будет наиболее простым/оптимальным.
В случае, если ваша проблема действительно заключается в нехватке аппаратных ресурсов, мониторинг должен довольно четко прояснить, где вы сейчас упираетесь в пределы и что вам следует купить (ядра ЦП или скорость ЦП, больше оперативной памяти, более быстрые диски) и куда это направить.
По моему опыту, более половины проблем с производительностью были более или менее легко решены с помощью правильной настройки, а не путем вбрасывания большего количества аппаратных ресурсов в проблему. Большинство разработчиков и слишком много поставщиков не имеют возможности или ресурсов для тестирования своих приложений и бэкэнда базы данных с тем же объемом данных и аналогичной нагрузкой, что и в производстве, и они делают предположения и проектные решения, которые не будут хорошо масштабироваться на практике.
Тщательный мониторинг даст вам представление о узких местах и о том, что вам, возможно, необходимо устранить на уровне приложения, базы данных или оборудования.
Обратите внимание, что анализ производительности и настройка — это одновременно и наука, и черное искусство.
Очень распространенные проблемы приложений, которые можно легко решить и которые часто обеспечивают значительные преимущества:
- отсутствующие индексы в базе данных
- пул соединений и кэширование запросов
- настройка лимитов памяти, количества соединений, сокетов и параллельных потоков приложений
Недостатки в дизайне приложения, которые сложнее устранить, возникают, когда на интерфейсе приложения слишком много логики обработки данных, а запросы к базе данных слишком просты, несвязанны и возвращают слишком много данных (например, с помощью SELECT * from GrowingDataSet). При мониторинге симптомы таких проблем могут быть самыми разными: высокая нагрузка на диск ввода-вывода на сервере базы данных, высокое потребление памяти на сервере приложений, перегруженные сетевые соединения. Каждый из них может использоваться для поддержки различных решений о покупке оборудования (обновление сервера базы данных до SSD-накопителей, увеличение оперативной памяти на сервере приложений, модернизация сети). Вероятно, ни один из них не понадобится, когда приложение начнет применять лучшую логику и разбиение на страницы в запросах.