Механизми за преразпределение на ресурси в esx(i)

Сайт на Delphi: ежедневни Delphi-новини, документация, статии, преглед, интервю, компютърен хумор.

Лимит, дялове, резервация са настройките, с които указваме как да разпределим ресурсите. А сега нека поговорим за механизмите, чрез които ESX(i) може да реализира тези настройки и как работи разпределението на сървърните ресурси между виртуалните машини.

От гледна точка на ESX(i), има три вида процесори:

- физически (физически, PCPU). Това са процесори, понякога казват "сокети". В зависимост от броя им се лицензира ESX(i);

- логически (логически, LCPU). Това са ядрата на физическия процесор. Физически ядра или, в случай на хипернапрежение, логически ядра. Всеки LCPU е една опашка от команди;

- виртуален (виртуален, VCPU). Един vCPU е един процесор за виртуална машина. Нека ви напомня, че може да има до осем процесора на виртуална машина.

Първото нещо, което трябва да кажете е:

- Един vCPU работи на един LCPU. Тоест виртуална машина с един виртуален процесор работи на едно ядро. Тоест, дори ако имате еднопроцесорен осемядрен сървър, работещ само с една виртуална машина с един процесор, той използва само едно ядро;

- но ако тази VM има осем vCPU, тогава тя използва всичките осем ядра -ESX(i) безотказно разделя процесорите на една VM на различни ядра;

- едно ядро може да изпълнява няколко vCPU на различни виртуални машини (фиг. 6.23).

Ориз. 6.23. Илюстрация на работа с процесорната подсистема Източник: VMware

Илюстрацията показва двупроцесорен сървър, като всеки процесор е двуядрен.

Хипервайзорът извършва балансиране на натоварването с интервал от 20 милисекунди, може да прехвърля vCPU между LCPU за по-добра производителност.рециклиране. Сервизната конзола винаги работи на CPU0, което е първото ядро на първия процесор.

Забележка. Ако сървърът е изграден на NUMA архитектура, тогава хипервайзорът ще вземе това предвид и ще се опита да постави всички vCPU на една VM на един процесор. Избягвайте да създавате виртуални машини с повече vCPU от броя на единичните процесорни ядра на NUMA сървъри. В последния случай хипервайзорът ще бъде принуден да изпълнява vCPU на една виртуална машина на ядрата на различни процесори, което ще забави достъпа до паметта.

По същите причини не трябва да разпределяте повече памет за виртуална машина, отколкото е локално достъпна за един процесор на физически сървър. Можете да определите тази стойност, например, като използвате esxtop, NUMA брояч.

Операционната система очаква всички нейни процесори да работят едновременно. В случая с физическите сървъри се случва точно това. Но в случай на виртуализация процесорите, видими за операционната система за гости, са виртуални процесори, които се управляват от хипервайзора. По-специално, хипервайзорът преразпределя ресурсите на физическите процесори (ядра) между много виртуални процесори. И точно защото на всяко физическо ядро работят няколко виртуални процесора, за хипервайзора е неудобно да разпределя цикли на виртуални процесори на една VM едновременно (все пак натоварването на различните физически ядра е различно, някъде в момента има свободни цикли, някъде не). И ако те не бъдат избрани едновременно, тогава OS за гости най-малко ще получи наказание за производителност, а най-много - ще изпадне в BSOD и паника на ядрото.

За предишни поколения хипервайзори този проблем беше решен от факта, че хипервайзорът проследяваше „извън синхрон“, тоест ситуацията, когато някои vCPU работят, а други не. Когато разликата в работното време достигне прагастойности (няколко милисекунди), хипервайзорът спря „изпреварващите“ vCPU и изчака възможността да разпредели процесорни цикли към всички vCPU на тази VM едновременно. Оказа се, че значителна част от времето всички няколко vCPU на тази виртуална машина са били неактивни. Това направи ESX версия 2.

Въпреки това, ESX(i) от версия 3 използва механизъм, наречен "Релаксирано съвместно планиране". Същността му се състои в това, че не всички vCPU на една виртуална машина трябва да получават цикли едновременно, а само тези, които са „изостанали“. Това намалява загубата на производителност поради виртуализацията, позволявайки по-ефективно използване на ресурсите на процесора на сървъра.

Този механизъм обаче не е панацея, така че трябва да се стремите да конфигурирате възможно най-малко vCPU за виртуални машини по отношение на производителността.

Забележка. Помощната програма на конзолата esxtop (resxtop за vCLI) показва времето за изчакване на синхронизирането в колоната %CSTP. По този начин тази стойност характеризира режийните разходи за виртуализация на процесори в многопроцесорна виртуална машина.

Също така в свойствата на VM в раздела Ресурси има ред Advanced CPU (фиг. 6.24).

Тук можете да зададете настройки за Hyperthreaded Core Sharing и CPU Affinity.

Ориз. 6.24. Разширени настройки на процесора

Hyperthreaded Core Sharing контролира как ще се използват логическите процесори, на които е разделено всяко физическо ядро, когато е активирана хипернишковостта. Позволете ми да ви напомня, че за процесори с активирана хипертърговия всяко физическо ядро генерира две логически, което теоретично ви позволява да изпълнявате някои команди в две нишки.

- Всеки - когато виртуалният процесор на тази VM работи на някое ядро, тогава други vCPU на тази и други виртуални машини могат да работят на второто логическо ядро на това физическо ядро;

- Internal - настройката е достъпна само за многопроцесорни виртуални машини. Когато виртуалните машини имат множество vCPU, те могат да работят на различни логически ядра на едно и също физическо ядро. За виртуални машини с един процесор тази настройка е еквивалентна на None;

- Няма - когато vCPU на тази виртуална машина започне да работи на някое физическо ядро, то го улавя напълно. Второто логическо ядро не работи. Само този vCPU от тази една VM работи на дадено ядро.

Моля, обърнете внимание, че тази настройка се нулира до стойността по подразбиране (Any), когато VM е в DRS клъстер или когато VM е мигриран към друг сървър. Приложимостта на тази настройка не е голяма - само за фина настройка на производителността на виртуални машини на един сървър. По правило ESX(i) управлява добре разпределението на ресурсите без наше участие.

Забележка. Няма ясни данни за ефективността на използването на хипер търговия за ESX(i). Като правило, производителността се променя леко, когато хипер търговията е активирана. Има малък шанс за влошаване на производителността от активирането на тази функция.

Scheduling Affinity - тук можем да посочим ядрата, на които могат да работят vCPU на тази виртуална машина. Ако по подразбиране хипервайзорът може да постави VM процесора на всяко ядро, тогава с тази настройка можем да ограничим неговия избор.

Ако променим тази настройка от стойността по подразбиране, тогава VM губи способността да мигрира на живо, което значително намалява приложимостта на тази настройка.