Я хочу обновить один из наших серверов, 8-ядерный сервер под управлением VMware Server 2. Виртуальные машины, которые он запускает, в основном являются веб-серверами, файловыми серверами и серверами электронной почты; в частности, он запускает три веб-сервера, 2 почтовых / файловых сервера и несколько серверов Jabber / XMPP.
Когда мы изначально настраивали эту машину, у нас были два веб-сервера, настроенные с двумя виртуальными ЦП. У нас были очень серьезные проблемы с производительностью. В то время у нас было всего 3 виртуальных машины с 5 виртуальными ЦП. Мы тоже бежали Сервер VMware 1 и RAID1. Мы перешли на RAID10, и я бы никогда не подумал о меньшем! :-)
На новом сервере будет VMware ESXi вместо VMware Server. Мы смотрим либо на другую 8-ядерную машину с более быстрыми процессорами, либо на 16- или 32-ядерный сервер. Я хочу быть уверенным, что избегаю проблем, которые у нас были раньше.
Поскольку раньше у меня были такие проблемы с несколькими виртуальными ЦП, мой план состоял в том, чтобы заменить виртуальную машину основного веб-сервера несколькими идентичными виртуальными машинами веб-сервера (2–4), каждая с одним виртуальным ЦП, обслуживающими контент из общего ресурса NFS, и поместить их в нагрузку. -балансированная конфигурация. Итак, я бы в основном заменил одну виртуальную машину по крайней мере 4: 2 небольшими виртуальными машинами веб-сервера, виртуальной машиной файлового сервера и виртуальной машиной балансировки нагрузки. У меня двоякий план: во-первых, я могу избежать использования нескольких виртуальных ЦП, которые я видел раньше, а во-вторых, я могу создавать новые виртуальные машины веб-сервера для обработки повышенной нагрузки.
Обратите внимание, что я понимаю, что я не получить все преимущества балансировки нагрузки, потому что у меня все еще есть единственная точка отказа.
Это хороший план или в нем нет необходимости? Может ли VMware ESXi обрабатывать несколько виртуальных ЦП лучше, чем VMware Server 1? более трех лет назад? Что будет работать лучше: одна большая виртуальная машина веб-сервера с 2–4 виртуальными ЦП или 4 виртуальные машины с одним виртуальным ЦП в конфигурации с балансировкой нагрузки?
Может ли VMware ESXi обрабатывать несколько виртуальных ЦП лучше, чем VMware Server 1 более трех лет назад?
Да, это полностью отдельные линейки продуктов, и ESXi очень хорошо справляется с несколькими виртуальными ЦП. Я использую 5-узловую ферму vmware прямо сейчас со смесью машин на каждой коробке, каждая с 1, 2, а в некоторых случаях 4 процессорами по мере необходимости, и она действительно работает очень хорошо.
Что будет работать лучше: одна большая виртуальная машина веб-сервера с 2–4 виртуальными ЦП или 4 виртуальные машины с одним виртуальным ЦП в конфигурации с балансировкой нагрузки?
Это не столько вопрос VMWare, сколько вопрос тестирования приложения / веб-сайта. VMWare (или любая другая современная виртуальная машина с «голым железом») может работать в любом случае - наличие большого количества виртуальных ЦП, подключенных к одному гостю, может быть связано с расходами, но это может быть компенсировано затратами ресурсов, связанных с запуском нескольких гостей, и проблемами производительности (или улучшения, если на то пошло) ваше веб-приложение может реализовать более распределенный подход.
Что касается последнего вопроса, то на самом деле это вопрос тестирования и архитектурных предпочтений, а не единственно верного пути, но я считаю, что если вы можете легко распределить приложение более чем на одну виртуальную машину, лучше построить несколько виртуальных машин меньшего размера. чем один большой. Дает вам больше гибкости и повышает производительность в долгосрочной перспективе, так как вы можете перемещать вещи, если вам нужно. Другими словами, масштабирование наружу, а не вверх
Я думаю, что с физическими машинами мы думаем о масштабировании вверх, помещая как можно больше в один «экземпляр» ОС, чтобы получить максимальную отдачу от стоимости лицензии и оборудования, но с виртуальными машинами эти уравнения немного меняются - если вы вы можете получить несколько экземпляров виртуальной ОС по цене лицензии, тогда это может изменить способ проектирования вашей серверной инфраструктуры.
редактировать
http://blog.peacon.co.uk/understanding-the-vcpu/ - это статья, упомянутая Яном при обсуждении этого вопроса в чате, в которой довольно подробно объясняется, почему важно думать о распределении vCPU при создании виртуальных машин.
Я могу ответить на этот вопрос разными способами, но я начну с горизонтального и вертикального масштабирования.
Плюсы
- Может масштабироваться очень широко
- Может масштабироваться между хостами (например, кластер VMware)
- Отказоустойчивой
- Низкое / полное отсутствие простоев во время обслуживания
Минусы
- Дополнительные накладные расходы от ОС виртуальных машин и балансировщиков нагрузки
- Больше обслуживания / управления (например, установка исправлений, сертификаты SSL)
- Больше управления версиями веб-сайтов на веб-серверах
- Для веб-сайта за балансировщиком нагрузки может потребоваться дополнительное тестирование и разработка.
- Лицензирование?
Плюсы
- Легче масштабируется (просто добавьте еще один или два виртуальных ЦП или больше памяти)
- Только один веб-сервер для управления, лицензирования и т. Д.
Минусы
- Время простоя во время обслуживания / обновлений
- Слишком большое масштабирование может вызвать проблемы с производительностью виртуальной машины.
- Не масштабируется.
Итак, у обоих есть свои плюсы и минусы, и я большой поклонник горизонтального масштабирования, но вот что я вам порекомендую:
Хорошо, а что это за конкретная точка вертикального масштабирования?
Это зависит от вашего оборудования.
VMware многое сделала для планирование виртуальных ЦП начиная с ESX 2.x, и есть больше возможностей для вертикального роста. Сколько на самом деле зависит от процессоров, которые вы получите.
Оценка производительности виртуальных машин в настоящее время требует понимания NUMA (неоднородный доступ к памяти. По сути, вы не хотите, чтобы виртуальная машина была больше, чем узел NUMA вашего процессора. Вот несколько ссылок, которые помогут вам в этой области:
http://frankdenneman.nl/2010/02/sizing-vms-and-numa-nodes/
http://frankdenneman.nl/2010/09/esx-4-1-numa-scheduling/
http://frankdenneman.nl/2011/01/amd-magny-cours-and-esx/
Думаю, я завершу это тем, что скажу, что процессор никогда не был для меня слишком большой проблемой, если только вы не увеличиваете подписку на процессор на своем хосте. Вместо этого обычно виновата память. Раздувание / подкачка памяти os a очень заметная проблема с производительностью.
Удачи!