Наскільки суперечка занадто велика у VMware?

Деякий час я намагаюся з'ясувати, чому досить багато наших критично важливих для бізнесу систем отримують повідомлення про "повільність", починаючи від легкої до крайньої. Нещодавно я звернув погляд на середовище VMware, де розміщуються всі розглянуті сервери.

Нещодавно я завантажив і встановив пробну версію пакета управління Veeam VMware для SCOM 2012, але мені важко вірити (і так це мій начальник) цифри, про які вона повідомляє мені. Щоб спробувати переконати мого начальника в тому, що цифри, про які він мені говорить, є правдивими, я почав шукати клієнта VMware, щоб перевірити результати.

Я переглянув цю статтю VMware KB ; конкретно для визначення Co-Stop, яке визначається як:

Кількість часу, коли віртуальна машина MP була готова до запуску, але виникала затримка через суперечки спільного планування vCPU

Який я перекладаю

Гостьовій ОС потрібен час від хоста, але він повинен чекати, коли ресурси стануть доступними, і тому їх можна вважати "невідповідними"

Чи здається цей переклад правильним?

Якщо так, ось тут мені важко повірити у те, що я бачу: Хост, який містить більшість віртуальних машин, які є "повільними", в даний час показує середнє значення CPU Co-stop 127,835,94 мілісекунд!

Чи означає це, що в середньому VM на цьому хості повинні чекати 2+ хвилин на час процесора ???

У цього хоста є два чотирьохпроцесорних процесора, він має 1х8 гості центрального процесора та 14х4 відвідувачів процесора.

Я можу описати деякий досвід, який я мав у цій галузі ...

Я не вірю, що VMware робить адекватну роботу з навчання клієнтів ( або адміністраторів ) про кращі практики, а також не оновлює колишні найкращі практики, коли їх продукти розвиваються. Це питання є прикладом того, як така концепція основної як розподіл vCPU не повністю зрозуміла. Найкращий підхід - почати з невеликого, з одного vCPU, поки не визначите, що для VM потрібно більше.

Для ОП хост-сервер ESXi має два чотирьохядерні процесори, що дають 8 фізичних ядер.

Описаний макет віртуальної машини - 15 загальних гостей; Системи 1 x 8 vCPU та 14 x 4 vCPU. Це занадто непомітно, особливо при наявності одного гостя з 8 vCPU . Це не має сенсу. Якщо вам потрібен VM настільки великий, вам, швидше за все, потрібен великий сервер.

Спробуйте спробувати ваші віртуальні машини потрібного розміру . Я впевнений, що більшість з них може жити з 2 vCPU. Додавання віртуальних процесорів не робить роботу швидше, тому, якщо це вирішує проблему з продуктивністю, приймати неправильний підхід.

У більшості середовищ оперативна пам’ять є найбільш обмеженим ресурсом. Але процесор може бути проблемою, якщо занадто багато суперечок. Ви маєте докази цього. Оперативна пам’ять також може бути проблемою, якщо занадто багато виділяється на окремі VM .

Це можливо контролювати. Ви шукаєте показник "Готовність процесора%". Ви можете отримати доступ до цього від клієнта vSphere, вибравши VM та перейшовши до Performance>> OverviewГрафік процесора.

• Менш 5% процесора готовий - у вас все добре.
• 5-10% процесора готовий - уважно стежте за діяльністю.
• Більше 10% процесора готовий - не добре.

Зверніть увагу на жовту лінію на графіку нижче.

Ви б не хотіли перевірити це на своїх проблемних віртуальних машинах та звітувати назад?

У коментарях ви заявляєте, що у вас є двоядерний чотирьохядерний ESXi-хост, і ви використовуєте один VV-модуль 8vCPU і чотирнадцять VV-модулів 4vCPU.

Якби це було моє середовище, я вважав би це надзвичайно затриманим . Я б максимум поставив чотири-шість гостей 4vCPU на це обладнання. (Це припускаючи, що VM, про які йдеться, має навантаження, яка вимагає від них такої високої кількості vCPU.)

Я припускаю, що ви не знаєте золотого правила ... за допомогою VMware ви ніколи не повинні призначати VM більше ядер, ніж потрібно. Причина? VMware використовує дещо суворе планування спільного планування, що ускладнює можливість віртуальних машин отримувати час процесора, якщо не буде стільки ядер, скільки призначено VM. Значить, VV 4VCPU не може виконати 1 одиницю роботи, якщо в той же момент відкриті 4 фізичні ядра. Іншими словами, архітектурно краще мати Vv 1PCPU з 90% завантаженням процесора, а потім мати 2vCPU VM з 45% навантаженням на ядро.

Отже ... ЗАВЖДИ створюйте VM з мінімальним числом vCPU, і додайте їх лише тоді, коли буде визначено необхідність.

Для вашої ситуації використовуйте Veeam для моніторингу використання процесора для ваших гостей. Зменшіть кількість vCPU на якомога більше. Я б хотів зробити ставку, що ви можете перейти до 2vCPU майже на всіх своїх існуючих гостей 4vCPU.

Зрозуміло, якщо всі ці віртуальні віртуальні машини насправді мають завантаження процесора, щоб вимагати підрахунку vCPU, він просто повинен придбати додаткове обладнання.

127 835,94 мілісекунд - це підсумок, і вам потрібно розділити час вибірки, щоб отримати правильні значення RDY%. Схоже, ви вже отримуєте правильні% RDY читання зараз. Ви можете пройти досить високий коефіцієнт vCPU до фізичного процесора, але не так, як це робите.

У вас дуже багато чотирьох VCPU VM і навіть 8 vCPU VM. Є деякі відповіді на якість, які вже обговорюють правильний розмір, а також деякі наслідки не консолідації циклів до менших vCPU. Я хотів уточнити одне, що, хоча це вже не так, VM повинен дочекатися, коли кількість фізичних процесорів, рівна його кількості vCPU, стане доступною до того, як будь-яка інструкція може бути оброблена, це дуже згубно. мати надмірну забезпеченість такої величини відношенням VMP з декількома VCPU до фізичних ядер. 64 vCPU на 8 ядер значно перевищує максимальне співвідношення 4 до 1. Я припускаю, що у вас є HT на цих процесорах, щоб у вас було 16 логічних ядер? Це може бути гаразд з 1 та 2 VCPU VM, що мають невелике навантаження, але якщо у вас велике навантаження на VM, це було б важко здійснити.

FYI Процесори HT не використовуються в обчисленні% використовуваних процесорів - це означає, що якщо на сервері у вас 32 логічних ядра, які працюють на частоті 2,4 ГГц, ви користуєтеся 100%, коли ви досягаєте 38,4 ГГц. Тож коли ви бачите, що середнє навантаження показує більше 1,0, саме тому.

Ось ESXi Host, який працює від 3,5 до 1 vCPU до фізичного процесора (включаючи ядра HT) із середнім рівнем 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, який пролив трохи світла на те, де стоять наші проблеми з продуктивністю. Переглядаючи екран Bottlenecks CPU у Veeam ONE, а потім використовуючи Виправлення неполадок віртуальної машини, яка перестала реагувати: Порівняння використання VMM та Guest CPU як орієнтир, ми з’ясували, де йдеться про наш «неприйнятний» розгляд.

Одним маленьким підказом, яким я хотів поділитися конкретно, є те, що в одному випадку я не міг усунути суперечки процесора, поки не видалив знімок, що був у VM. Сподіваюся, що це комусь допоможе.