Обяснени Hyper-V виртуални процесори - Altaro

Вашият софтуерен доставчик посочи ли, че можете да виртуализирате тяхното приложение, но само ако му посветите едно или повече процесорни ядра? Не е ясно какво се случва, когато присвоите процесори на виртуална машина? Далеч не сте сами.

Забележка: Тази статия е публикувана първоначално през февруари 2014 г. Тя е напълно актуализирана, за да бъде актуална към ноември 2019 г.

Въведение във виртуалните процесори

Както всички останали „хардуери“ на виртуални машини, виртуалните процесори не съществуват. Хипервайзорът използва реалните процесори на физическия хост, за да създаде виртуални конструкции, които да представи на виртуални машини. Хипервайзорът контролира достъпа до реалните процесори точно както контролира достъпа до целия друг хардуер.

Hyper-V никога не присвоява физически процесори на конкретни виртуални машини

Уверете се, че разбирате този раздел, преди да продължите. Присвояването на 2 vCPU на система не означава, че Hyper-V изважда две ядра от физическия пул и ги свързва за постоянно с вашата виртуална машина. Не можете изобщо да присвоите физическо ядро ​​на VM. И така, това означава ли, че просто не можете да изпълните искането на доставчика да посветите едно или две ядра? Е, не точно. Повече за това към края.

Разбиране на планирането на процесора на операционната система

Нека започнем с това, като разгледаме как се използват процесорите в обикновен Windows. Ето снимка на моя екран на диспечера на задачите:

Нищо изискано, нали? Изглежда познато, нали?

Сега, когато компютрите никога или почти никога не са се доставяли като многопроцесорни многоядрени кутии, всички знаехме, че компютрите наистина не могат да изпълняват много задачи едновременно. Те имаха един процесор и едно ядро, така че имаше само една възможна активна нишка за изпълнение. Но освен фантастичните графични актуализации, Task Manager тогава изглеждаше почти като Task Manager сега. Имахте дълъг списък от работещи процеси, всеки с показател, показващ какъв процент от времето на процесорите използва.

Тогава, както сега, всеки ред, който виждате, представлява процес (или, ново в последните версии на диспечера на задачите, група процеси). Процесът се състои от една или повече нишки. Нишката не е нищо повече от последователност от инструкции на процесора (ключова дума: последователност).

Това, което се случва е, че (в Windows това започна в 95 и NT) операционната система спира работеща нишка, запазва нейното състояние и след това стартира друга нишка. След известно време той повтаря тези операции за следващата нишка. Наричаме това превантивно, което означава, че операционната система решава кога да спре текущата нишка и да превключи към друга. Можете да зададете приоритети, които влияят върху скоростта на процеса, но операционната система отговаря за планирането на нишките.

Днес почти всички компютри имат множество ядра, така че Windows наистина може да изпълнява много задачи.

Пренасяне на тези концепции в хипервайзора

Поради ролята си на мениджър на нишки, Windows може да се нарече „супервайзор“ (много стара терминология, която наистина никога вече не виждате): система, която управлява процеси които са съставени от нишки. Hyper-V е хипервайзор: система, която управлява супервайзори, които управляват процеси, които са съставени от нишки.

Диспечерът на задачите не работи по същия начин за Hyper-V, но се случва същото. Има списък с дялове, а вътре в тези дялове има процеси и нишки. Планировчикът на нишки работи почти по същия начин, нещо подобно:

Разбира се, една реална система винаги ще има повече от девет работещи нишки. Планировчикът на нишки ще ги постави всички в опашка.

Какво ще кажете за афинитета на процесора?

Вероятно знаете, че можете да афинизирате нишки в Windows, така че те винаги да работят на конкретно ядро ​​или набор от ядра. Не можете да направите това в Hyper-V. Така или иначе би имало съмнителна стойност; посвещаването на нишка на ядро ​​не е същото нещо като посвещаването на ядро ​​на нишка, което много хора наистина искат да опитат да направят. Не можете да попречите на едно ядро ​​да изпълнява други нишки в света на Windows или света на Hyper-V.

Как работи планирането на нишки?

Най-простият отговор е, че Hyper-V взема решението на ниво хипервизор. Това всъщност не позволява на гостите да участват. Гост операционните системи планират нишките от процесите, които притежават. Когато изберат нишка за изпълнение, те я изпращат до виртуален процесор. Hyper-V го взема оттам.

Изображението, което представих по-горе, непременно е прекалено опростено, тъй като не е просто първи влязъл, първи излязъл. NUMA играе роля, например. Истинското разбиране на тази тема изисква доста дълбоко гмуркане в някои сложни идеи. Малко администратори изискват това ниво на дълбочина и изследването му тук би отвело тази статия далеч.

Първото нещо, което има значение: като оставим настрана афинитета, никога не знаете къде ще се изпълни дадена нишка. Нишка, която е била поставена на пауза, за да даде процесорно време на друга нишка, може много добре да бъде присвоена на друго ядро, когато бъде възобновена. Чудили ли сте се някога защо едно приложение консумира точно 50% от двуядрена система и всяко ядро ​​изглежда, че работи с 50% използване? Това поведение показва еднопоточно приложение. Всеки път, когато планировчикът го изпълни, той консумира 100% от ядрото, върху което се приземява. Следващия път, когато се стартира, той остава на същото ядро ​​или преминава към другото ядро. Към което и ядро ​​да го присвои планировчикът, то консумира 100%. Когато Task Manager обобщава своята производителност за показване, това е дори 50% използване — приложението използва 100% от 50% от капацитета на системата. Тъй като ядрото, което не работи с приложението, остава предимно неактивно, докато другото ядро ​​достига върха, те кумулативно възлизат на 50% използване за измерения период от време. С възможностите на по-новите версии на диспечера на задачите вече можете да го инструктирате да показва отделните ядра поотделно, което прави това поведение много по-очевидно.

Сега можем да преминем към разглеждане на броя vCPU, присвоени на система и приоритет.

Какво всъщност означава броят vCPU, присвоени на VM?

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

И така, броят на vCPU на една виртуална машина означава следното: максималният брой нишки, които VM може да изпълнява във всеки даден момент. Не мога да настроя виртуалната машина от екранната снимка да има повече от два vCPU, защото хостът има само два логически процесора. Следователно няма къде да бъде планирана трета нишка. Но ако имах 24-ядрена система и оставях тази виртуална машина на 2 vCPU, тогава тя ще изпрати максимум две нишки към Hyper-V за планиране. Планировчикът на нишки на виртуалната машина (надзорникът) ще запази другите си нишки в опашка, чакайки своя ред.

Но не мога ли да присвоя повече общи vCPU на всички виртуални машини, отколкото физически ядра?

Да, общият брой vCPU във всички виртуални машини може да надвишава броя на физическите ядра в хоста. Това не е по-различно от факта, че имам 40+ процеса, които „работят“ на моя двуядрен лаптоп в момента. Мога да изпълнявам само две нишки наведнъж, но винаги ще планирам много повече от две нишки. Windows прави това от много дълго време и Windows е толкова добър в това (обикновено), че повечето хора никога не виждат нужда да обмислят какво се случва. Вашите виртуални машини (надзорни органи) ще създават нишки за изпълнение и Hyper-V (хипервайзор) ще ги планира по начина (предимно), по който Windows ги планира, откакто надмина кооперативното планиране в Windows 3.x.

Какво е правилното съотношение между vCPU и pCPU/ядра?

Това е въпросът, който вълнува всички. Ще ви кажа направо: в общия смисъл този въпрос няма отговор.

Разбира се, много назад хората казваха 1:1. Някои хора го казват и днес. И знаете ли, можете да го направите. Разточително е, но можете да го направите. Бих могъл да стартирам текущата си конфигурация на работния плот на четириядрен 16-ядрен сървър и никога няма да получа никакво съревнование. Но вероятно няма да видя голяма разлика в производителността. Защо? Защото почти всичките ми нишки стоят бездействащи почти през цялото време. Ако нещо се нуждае от 0% процесорно време, какво прави предоставянето на собствено ядро? Нищо, ето какво.

По-късно отговорът беше надстроен до 8 vCPU на 1 физическо ядро. Добре, разбира се, добре.

След това станаха 12.

След това препоръките изчезнаха.

Те си тръгнаха, защото никой наистина няма представа. Планировчикът ще разпредели равномерно нишките в наличните ядра. Така че количеството необходими физически процесори не зависи от това колко виртуални процесори има. Зависи изцяло от това от какво се нуждаят операционните нишки. И дори ако имате куп тежки нишки, това не означава, че техните системи ще умрат, тъй като бъдат изместени от други тежки нишки. Необходимото съотношение vCPU/pCPU зависи изцяло от профила на натоварване на процесора и вашия толеранс за латентност. Множеството тежки товари изискват ниско съотношение. Няколко големи натоварвания работят добре със средно съотношение. Леките товари могат да работят на система с високо съотношение.

Ще ви разкрия една мръсна малка тайна за процесорите: всеки път, когато нишка се изпълнява, без значение каква е, тя задвижва процесора на 100% (регулирането на мощността променя тактовата честота, а не натоварването насищане). Централният процесор е двоично устройство; или се обработва, или не. Когато вашите инструменти за измерване на ефективността ви покажат това 100%, или 20%, или 50%, или каквото и да е число, те го изчисляват от измерване на времето. Ако видите 100%, това означава, че процесорът е обработвал през целия измерен период от време. 20% означава, че е изпълнявал процес 1/5 от времето и 4/5 от времето, когато е бил неактивен. Това означава, че една нишка не консумира 100% от процесора, защото Windows/Hyper-V ще я изпревари, когато иска да изпълни друга нишка. Можете да имате множество „100%“ CPU нишки, работещи на една и съща система. Дори и така, една система може да реагира само когато има известно време на празен ход, което означава, че повечето нишки просто ще оставят техния отрязък от време да мине. Това позволява на други нишки да имат по-бърз достъп до ядрата. Когато имате множество нишки, които винаги са на опашка за активно процесорно време, цялостната система става по-малко отзивчива, защото нишките трябва да чакат. Използването на допълнителни ядра ще реши този проблем, тъй като разпределя натоварването.

Резултатът: ако искате да знаете колко физически ядра имате нужда, тогава трябва да знаете профила на производителност на вашето действително натоварване. Ако не знаете, тогава започнете от по-ранните препоръки 8:1 или 12:1.

[thrive_leads id=’17165′]

Какво ще кажете за резерва и претеглянето (приоритет)?

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

Нека да разгледаме екрана за конфигурация:

Първата група кутии е резервната. Първото поле представлява процента от неговия разрешен брой vCPU за заделяне. Действителното му значение зависи от броя на vCPU, присвоени на VM. Второто поле, оцветеното в сиво, показва общия процент от хост ресурсите, които Hyper-V ще задели за тази виртуална машина. В този случай имам система с 2 vCPU на двуядрен хост, така че двете кутии ще бъдат еднакви. Ако задам 10 процента резерв, това са 10 процента от общите физически ресурси. Ако намаля разпределението до 1 vCPU, тогава 10 процента резерв стават 5 процента физически. Второто поле ще бъде автоматично изчислено, докато коригирате първото поле.

Резервът е твърд минимум... нещо като. Ако сборът от всички резервни настройки на всички виртуални машини на даден хост надвиши 100%, тогава поне една виртуална машина няма да стартира. Но ако резервът на VM е 0%, тогава той изобщо не се брои към 100% (изглежда доста очевидно, но никога не се знае). Но ако VM с 20% резерв не работи, тогава на други процеси е позволено да използват до 100% от наличната мощност на процесора... до момента, в който VM с резерв се стартира. След това, след като капацитетът на процесора е наличен, запазената виртуална машина ще може да доминира до 20% от общата изчислителна мощност. Тъй като времевите отрязъци са толкова кратки, всъщност винаги има 20% налични, но трябва да чака като всички останали.

И така, този доставчик, който иска специален процесор? Ако наистина искате да уважите желанията им, ето как го правите. Въвеждате каквото и да е число в горното поле, което кара второто поле да показва еквивалентната процесорна мощност на колкото и много pCPU/ядра, които продавачът смята, че имат нужда. Ако искат един цял процесор и имате четириядрен хост, тогава направете второто поле да показва 25%. Наистина ли трябва? Е, не знам. Техният софтуер вероятно не се нуждае от такъв тип мощност, но ако могат да ви изгонят от поддръжката, защото не ги слушате, добре... не ме вкарвайте в това. Истинската причина, поради която плътността на виртуализацията никога не достига това, което производителите на хипервайзори казват, че могат да направят, е поради произволните правила на доставчиците на софтуер, но това е дума за друг ден.

Следващите две полета са ограничението. Сега, след като разбирате резерва, можете да разберете и лимита. Това е ограничение на ресурсите. Той държи ръцете на алчни VM далеч от буркана с бисквитки. Двете кутии работят заедно по същия начин като резервните кутии.

Последното поле е приоритетното тегло. Както беше посочено, това е относително. Всяка виртуална машина, настроена на 100 (по подразбиране), има същото привличане с планировчика, но всички те са под всички виртуални машини, които имат 200 и над всички виртуални машини, които имат 50, така нататък и така нататък. Ако възнамерявате да бъркате, теглото е по-безопасно, отколкото да се занимавате с резерви, защото никога не можете да попречите на VM да стартира чрез промяна на относителните тегла. Това, което означава теглото, е, че когато група виртуални машини представят нишки на планировчика на нишки на хипервайзора наведнъж, първо претеглят виртуалните машини с по-високо тегло.

Но какво да кажем за Hyper-Threading?

Hyper-Threading позволява на едно ядро ​​да управлява две нишки наведнъж — нещо като. Ядрото може активно да изпълнява само една от нишките в даден момент, но ако тази нишка спре, докато чака външен ресурс, тогава ядрото управлява другата нишка. Можете да прочетете по-подробно обяснение по-долу в секцията за коментари от сътрудника Jordan. AMD наскоро добави подобна технология.

За да убием едно основно погрешно схващане: Hyper-Threading не удвоява способността за производителност на ядрото. Синтетичните бенчмаркове показват най-висока стойност от 25% подобрение. По-реалистичните измервания показват по-близо до 10% увеличение. 8-ядрена Hyper-Threaded система не работи толкова добре, колкото 16-ядрена система без Hyper-Threaded. Може да работи почти толкова добре, колкото 9-ядрена система.

С така наречения „класически“ планировчик, Hyper-V поставя нишки на следващото налично ядро, както е описано по-горе. С основния планировчик, въведен в Hyper-V 2016, Hyper-V вече предотвратява нишките, притежавани от различни виртуални машини, да работят една до друга на едно и също ядро. Той обаче ще продължи да изпреварва нишките на една виртуална машина в полза на друга. Имаме статия, която се занимава с основния планировчик.

Осъзнаване на всичко

Знам, че това е много информация. Повечето хора идват тук, за да знаят колко vCPU да присвоят на VM или колко общо vCPU да работят на една система.

Лично аз присвоявам 2 vCPU на всяка виртуална машина за стартиране. Това му дава поне две места за стартиране на нишки, което му осигурява отзивчивост. В двупроцесорна система също така гарантира, че виртуалната машина автоматично присъства и в двата NUMA възела. Не присвоявам повече vCPU на VM, докато не знам, че се нуждае от него (или доставчик на приложение го изисква).

Що се отнася до съотношението между vCPU и pCPU, това работи почти по същия начин. Няма формула или магическо знание, което можете просто да приложите. Ако планирате да виртуализирате съществуващи натоварвания, тогава измерете тяхното текущо използване на процесора и го отчетете; това ще ви каже какво трябва да знаете. Инструментариумът на Microsoft за оценка и планиране може да ви помогне. В противен случай просто добавяте ресурси и наблюдавате използването. Ако вашият хардуер не може да се справи с работното ви натоварване, тогава трябва да мащабирате.