Сколько разногласий слишком много в VMware?
Некоторое время я пытался выяснить, почему многие из наших критически важных для бизнеса систем получают отчеты о «медлительности», варьирующейся от легкой до экстремальной. Недавно я обратил внимание на среду VMware, в которой размещены все рассматриваемые серверы.
Я недавно загрузил и установил пробную версию пакета управления Veeam VMware для SCOM 2012, но мне трудно поверить (и моему боссу) в цифры, которые он мне сообщает. Чтобы убедить своего босса, что цифры, которые он мне сообщает, верны, я начал изучать сам клиент VMware, чтобы проверить результаты.
Я смотрел на эта статья базы знаний VMware; специально для определения Co-Stop, который определяется как:
Время, в течение которого виртуальная машина MP была готова к запуску, но возникла задержка из-за конфликта планирования совместного виртуального ЦП
На что я перевожу
Гостевой ОС требуется время от хоста, но она должна ждать, пока станут доступны ресурсы, и поэтому может считаться "не отвечающей".
Этот перевод кажется правильным?
Если это так, то вот где мне трудно поверить в то, что я вижу: хост, содержащий большинство «медленных» виртуальных машин, в настоящее время показывает среднее значение CPU Co-stop, равное 127 835,94 миллисекунды!
Означает ли это, что в среднем виртуальным машинам на этом хосте приходится ждать более 2 минут процессорного времени ???
На этом хосте есть два 4-ядерных процессора, гостевой процессор 1x8 и гостевой процессор 14x4.
Вы указываете в комментариях, что у вас есть двухъядерный четырехъядерный хост ESXi, и вы используете одну виртуальную машину 8vCPU, и 14 ВМ 4vCPU.
Если бы это было мое окружение, я бы счел это грубо избыточно подготовлен. Я бы поставил на это оборудование не более четырех-шести гостей с 4vCPU. (Предполагается, что рассматриваемые виртуальные машины имеют нагрузку, которая требует от них такого высокого количества виртуальных ЦП.)
Я предполагаю, что вы не знаете золотого правила ... с VMware вы никогда не должны назначать виртуальной машине больше ядер, чем ей нужно. Причина? VMware использует несколько жесткое совместное планирование, из-за чего виртуальным машинам трудно получить время ЦП, если не имеется столько доступных ядер, сколько назначено виртуальной машине. Это означает, что виртуальная машина 4vCPU не может выполнять 1 единицу работы, если одновременно не открыто 4 физических ядра. Другими словами, с архитектурной точки зрения лучше иметь виртуальную машину 1vCPU с 90% загрузкой ЦП, чем иметь виртуальную машину 2vCPU с 45% нагрузкой на каждое ядро.
Итак ... ВСЕГДА создавайте виртуальные машины с минимальным количеством виртуальных ЦП и добавляйте их только тогда, когда это необходимо.
В вашей ситуации используйте Veeam для отслеживания загрузки ЦП гостями. Уменьшите количество виртуальных ЦП, насколько это возможно. Я готов поспорить, что вы можете перейти на 2vCPU почти на всех ваших гостевых системах с 4vCPU.
Конечно, если у всех этих виртуальных машин действительно есть загрузка ЦП, требующая наличия у них количества виртуальных ЦП, то вам просто нужно купить дополнительное оборудование.
Я могу описать некоторые из своих переживаний в этой области ...
Я не верю, что VMware адекватно обучает клиентов (или администраторы) о передовых практиках, а также они не обновляют прежние передовые практики по мере развития своих продуктов. Этот вопрос является примером того, как основная концепция, такая как выделение виртуальных ЦП, не совсем понятна. Наилучший подход - начать с малого, с одним виртуальным ЦП, пока вы не определите, что виртуальной машине требуется больше.
Для OP хост-сервер ESXi имеет два четырехъядерных процессора, что дает 8 физических ядер.
Описываемая структура виртуальной машины составляет всего 15 гостей; Системы 1 x 8 vCPU и 14 x 4 vCPU. Это слишком чрезмерно, особенно с учетом существования один гость с 8 виртуальными ЦП. Это не имеет никакого смысла. Если вам нужна такая большая виртуальная машина, вам, вероятно, понадобится более крупный сервер.
Пожалуйста, попробуйте правильный размер ваши виртуальные машины. Я почти уверен, что большинство из них могут жить с двумя виртуальными ЦП. Добавление виртуальных процессоров не ускоряет работу, поэтому, если это решение проблемы с производительностью, это неправильный подход.
В большинстве сред оперативная память является наиболее ограниченным ресурсом. Но процессор может стать проблемой, если будет слишком много споров. У вас есть доказательства этого. ОЗУ также может быть проблемой, если слишком много выделено отдельным ВМ.
За этим можно следить. Вам нужна метрика «CPU Ready%». Вы можете получить к нему доступ из клиента vSphere, выбрав виртуальную машину и перейдя в Performance > Overview > График ЦП.
- Готовность к процессору менее 5% - Ты в порядке.
- Готовность процессора 5-10% - Внимательно следите за деятельностью.
- Готовность к процессору более 10% - Не хорошо.
Обратите внимание на желтую линию на графике ниже. 
Не могли бы вы проверить это на проблемных виртуальных машинах и отчитаться?
127 835,94 миллисекунды - это сумма, и вам нужно разделить на время выборки, чтобы получить правильные значения% RDY. Похоже, вы уже получаете правильные показания% RDY. Вы можете достичь довольно высокого уровня с соотношением виртуальных и физических процессоров, но не так, как вы это делаете.
У вас слишком много виртуальных машин с четырьмя виртуальными ЦП и даже с 8 виртуальными ЦП. Уже есть несколько качественных ответов, в которых обсуждается правильный выбор размера и некоторые последствия отказа от консолидации циклов для меньшего количества виртуальных ЦП. Единственное, что я хотел прояснить, это то, что, хотя виртуальная машина больше не должна ждать, пока количество физических процессоров, равное ее количеству vCPU, станет доступным, прежде чем любая инструкция может быть обработана, это очень пагубно. иметь избыточное выделение ресурсов такого масштаба при соотношении виртуальных машин с несколькими виртуальными ЦП к физическим ядрам. 64 виртуальных ЦП на 8 ядрах - это намного больше, чем максимальное соотношение 4: 1. Я полагаю, у вас есть HT на этих процессорах, поэтому у вас 16 логических ядер? Это может быть нормально для виртуальных машин с 1 и 2 виртуальными ЦП, которые имеют небольшую нагрузку, но если у вас большая нагрузка на виртуальные машины, это будет сложно выполнить.
К вашему сведению, процессоры HT не используются в вычислениях процента использования ЦП - это означает, что если у вас есть 32 логических ядра, работающих на частоте 2,4 ГГц на сервере, вы используете 100% при достижении частоты 38,4 ГГц. Поэтому, когда вы видите, что средняя нагрузка больше 1.0, вот почему.
Вот хост ESXi, на котором соотношение виртуальных ЦП к физическому процессору (включая ядра HT) составляет 3,5: 1 со средним% RDY, равным 3%.
11:13:49pm up 125 days 7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37
%USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
13.51 15.87 0.50 580.17 0.03 4.67 66.47 0.29 0.00 0.00 0.00
15.24 18.64 0.43 491.54 0.04 4.65 63.70 0.43 0.00 0.00 0.00
13.44 16.40 0.44 494.10 0.02 4.33 66.24 0.48 0.00 0.00 0.00
13.75 16.30 0.51 494.26 0.32 4.32 66.06 0.35 0.00 0.00 0.00
17.56 20.72 0.58 489.35 0.04 4.31 60.76 0.45 0.00 0.00 0.00
13.82 16.43 0.50 494.12 0.07 4.31 66.26 0.26 0.00 0.00 0.00
13.65 16.81 0.49 493.81 0.03 4.21 65.93 0.37 0.00 0.00 0.00
13.73 16.51 0.42 493.63 0.09 4.06 66.24 0.29 0.00 0.00 0.00
13.89 16.37 0.55 580.61 0.04 3.95 66.69 0.28 0.00 0.00 0.00
14.02 17.00 0.33 494.11 0.03 3.93 66.10 0.29 0.00 0.00 0.00
13.44 15.84 0.49 495.17 0.04 3.87 67.24 0.27 0.00 0.00 0.00
13.59 15.84 0.50 580.27 0.04 3.81 67.24 0.44 0.00 0.00 0.00
17.10 19.86 0.50 490.97 0.04 3.74 62.21 0.39 0.00 0.00 0.00
13.32 15.77 0.50 495.34 0.03 3.73 67.47 0.27 0.00 0.00 0.00
13.43 16.15 0.48 494.95 0.05 3.72 67.09 0.38 0.00 0.00 0.00
13.44 16.47 0.49 580.88 0.04 3.72 66.81 0.40 0.00 0.00 0.00
13.71 17.00 0.29 494.13 0.03 3.71 66.26 0.37 0.00 0.00 0.00
17.34 20.41 0.39 490.50 0.05 3.70 61.70 0.37 0.00 0.00 0.00
13.42 16.19 0.50 495.07 0.03 3.66 67.15 0.38 0.00 0.00 0.00
13.56 16.23 0.48 494.97 0.03 3.60 67.12 0.30 0.00 0.00 0.00
14.95 17.53 0.42 578.82 0.09 3.57 65.72 0.35 0.00 0.00 0.00
13.44 16.07 0.56 581.14 0.04 3.54 67.34 0.40 0.00 0.00 0.00
17.19 21.27 0.37 575.41 0.04 3.44 61.08 0.51 0.00 0.00 0.00
13.57 16.99 0.30 580.64 0.01 3.37 66.69 0.38 0.00 0.00 0.00
13.79 16.25 0.43 495.25 0.04 3.35 67.39 0.39 0.00 0.00 0.00
11.90 14.67 0.30 496.86 0.02 3.31 69.00 0.36 0.00 0.00 0.00
17.13 19.28 0.56 491.83 0.03 3.30 63.26 0.48 0.00 0.00 0.00
14.01 16.17 0.50 495.56 0.01 3.30 67.66 0.39 0.00 0.00 0.00
16.86 20.16 0.57 491.19 0.05 3.20 62.44 0.43 0.00 0.00 0.00
14.94 17.46 0.42 580.05 0.08 3.16 66.24 0.40 0.00 0.00 0.00
14.56 16.94 0.36 494.86 0.08 3.14 66.91 0.42 0.00 0.00 0.00
......
С тех пор мы установили Veeam ONE, который пролил свет на наши проблемы с производительностью. Посмотрев на экран «Узкие места ЦП» в Veeam ONE, затем используя Устранение неполадок виртуальной машины, которая перестала отвечать: сравнение использования VMM и гостевого ЦП в качестве справки мы выяснили, в чем заключается наша «неприемлемость».
Один маленький совет, которым я хотел бы поделиться, заключается в том, что в одном случае я не мог устранить конфликт ЦП, пока не удалил моментальный снимок, который был на виртуальной машине. Надеюсь, это кому-то поможет.