виртуализация на процесора: технологията, движеща икономиката на облака

Можем да наемем толкова или толкова малък изчислителен капацитет, съхранение или свързаност, колкото искаме, и можем да ги получим, когато поискаме. И ние не трябва да поддържаме или отчитаме нищо от този хардуер. Каква страхотна идея, този облак. Защо това не е направено отдавна? И компаниите, предоставящи всички тези ресурси, все повече ни правят лесни за използване. Животът в света на ИТ определено изглежда добър.

Онези, които ни предоставят облака, обаче знаят, че – както при почти всичко – този добър живот идва с няколко компромиса. Съвсем не е, че тези предупреждения са скрити, просто е необходима известна техническа подготовка, за да се обясни лесно. Защо, например, един ден производителността на моето базирано в облак приложение е страхотна, а на следващия ден не е, дори и при всички останали  – от наша гледна точка – да са еднакви? Възможните причини наистина не са толкова трудни за разбиране. Така че тук ще се съсредоточим върху виртуализацията на процесора, набор от технически концепции, които са в основата на поне част от облака.

Наистина ли имате избор да не разберете това? Както прочетох в скорошна статия за The Next Platform: „Днес компаниите оперират с един крак на място и друг в облака. Тази комбинация от частни и публични активи, предоставящи основни бизнес услуги, е известна като хибридно предприятие и се превърна в новото нормално. Въпреки че този модел може да намали разходите и да подобри производителността на служителите, той също може да бъде кошмар за управлението на ИТ.” Малко допълнителни знания трябва да помогнат тук.

Абсолютно ще говорим за това какво стимулира производителността, но това не е – и наистина трябва да се разбира – статия за изчислителната производителност като цяло; това е статия за разликите между използването на публични и частни активи.

И така, облегнете се и нека изградим няколко ментални образа за това, което наистина се случва в тези облаци.

НАЧАЛНА ТОЧКА

Разбира се, част от красотата на облака е, че можете да наемете неговите ресурси. Но това е възможно от един доста прост факт; обикновено използвате само малък процент от изчислителните ресурси, налични на хардуера, на който изпълнявате. Ако използвате – да речем – само 10 процента, защо плащате и за останалите 90 процента? Вместо това наемете това, от което се нуждаете.

Онези, които управляват облака, разбира се, имат и са платили за хардуера и така целия изчислителен капацитет, който идва с него. И често много. И те са напълно готови да ви позволят да споделяте – до някакъв лимит – този хардуер, да плащате номинална сума за привилегията и пак да ви гарантират, че сте функционално изолирани от всички останали обитатели на облака. Във всеки случай това всъщност е всъщност виртуализацията на процесора; споделяне на хардуера по някакъв защитен начин, но по такъв начин, че наличният капацитет в този хардуер да се използва по-пълноценно.

Когато видим снимки на това, което наистина съставлява облака(ите), със сигурност изглежда, че нашите собствени отпечатъци от употреба са необяснимо малки в нещо невъобразимо масивно; всеки изглежда като купчина и купчина изчислителен капацитет, памет, постоянно съхранение и връзки с огромна честотна лента. Вие крещите в нещо толкова силно и очаквате да чуете ехо; тоест, дори ако можете да чуете нещо различно от охлаждащите вентилатори.

Но не, всъщност не е така. Всеки облак е изграден до голяма степен от хардуера, който вече познавате и обичате. Много от тях са масивни копия на една до няколко платки, поддържащи SMP (симетричен мултипроцесор), всяка с един до няколко процесорни чипа, всеки чип с голяма шепа процесорни ядра, всяка с доста малко кеш памет и обща памет на поразително разстояние от терабайт памет. И тези градивни елементи от своя страна поддържат връзки със съседи, други I/O устройства и външния свят чрез PCI-Express, Ethernet, InfiniBand и други. В сравнение с не много отдавна, дори тези отделни SMP градивни елементи са мощни единици. А за тези, които се нуждаят от повече, повече на по-висока цена, все още има по-големи SMP системи – или такива с графични процесори – които могат да бъдат възпроизведени по подобен начин. облакът не е толкова масивна мъгла, колкото голям брой горещи снежни топки; това е облак, защото не е нужно да знаете къде се намирате, докато сте в него, не че е изцяло ваш за използване.

Всички тези SMP единици може да изглеждат големи сами по себе си – изчислителният капацитет на множество десетки процесори и стотици гигабайти памет в крайна сметка – но те са ограничени. А работата на облачния доставчик е да посрещне и надхвърли вашите нужди от производителност, като намали вашите разходи, като същевременно минимизира техните разходи – които включват огромни енергийни разходи – и максимизира печалбите си, като същевременно вмести вас и другите в тези ограничени ресурси. Балансирането на натоварването за постигане на това е издигнато до висша наука тук.

Те не дават на вашата операционна система и нейните приложения цяла процесорна платка; вместо това те ви предоставят нещо много по-абстрактно, Compute Capacity. Вие и десетки, стотици, може би хиляди други екземпляри на операционна система – известни още като дялове – споделяте общия капацитет на едно SMP устройство. Отново, вие не купувате или дори непременно наемате определен брой процесорни ядра, вие споделяте този ресурс и наемате част от неговия капацитет.

Сключили сте договор за определено ниво на капацитет; както и много, много други. облачните доставчици вземат вашите желани и действителни нужди от производителност, разглеждат наличния капацитет във всеки и целия им действителен и активен в момента хардуер, коригират потреблението на енергия и решават къде в този огромен облак вашият дял ще пребивава за известно време; пребиваващ там, в това SMP звено, заедно с цял куп други.

Това е отправната точка. След това ще се поразровим малко и ще видим какво означава това и как може да го почувствате.

КАКВО Е КАПАЦИТЕТ?

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

Да предположим, че измервате някаква единица работа, която наричате „транзакция“. Да предположим, че в момента вашата система извършва 1000 транзакции в секунда. И сте забелязали, че използването на процесора е - да речем - 20%. Какво е вашето автоматично предположение за наличния капацитет на вашата система? Вероятно си мислите, че тези 20% използване на процесора означават, че моите процесори могат да поемат 5 пъти повече работа. Следователно трябва да мога да получа приблизително 5 пъти повече транзакции – 5 пъти повече пропускателна способност; това предполага, че този SMP е процесор – не I/O – ограничен. И така, 5 по 1000, общият наличен капацитет е около 5000 транзакции/секунда. Отново, това е вашата автоматична оценка, когато погледнете използването на процесора.

Възможно е също така да сте измерили своята пропускателна способност, базирана на транзакции, с течение на времето, като сте забелязали всякакви интересни взаимовръзки относно скоростите на транзакциите с течение на времето, може би дори нанасяйки това върху използването на процесора. Може дори да сте стигнали толкова далеч, че да определите изчислителния капацитет за брой ядра, необходим за стимулиране на тази пропускателна способност с течение на времето; ако вашата 16-ядрена система често е била с 25 процента използване, може би бихте могли да свършите същата работа с 4 ядра. Забелязахте, че обикновено ви е необходима само малка част от вашите – да кажем – шестнадесет ядра; можеше да се справиш с наличния капацитет в тези много по-малко ядра, но много понякога знаеш, че можеш да използваш повече. Добра работа. Готови сте да закупите едно или повече от икономическите предложения на Cloud.

Вярвате или не, вие сте направили много предположения в този хубав анализ, много от тях достатъчно валидни, други – добре – ще говорим за тях скоро.

Капацитетът е концептуално близък до понятието пропускателна способност. Да имаш способността – възможността – да произвеждаш по-висока пропускателна способност – по-високи транзакции/секунда – също означава да имаш по-висок капацитет. Скоростта на транзакция е мярка за пропускателна способност; капацитетът е максималната скорост на транзакция, която може да бъде постигната. Не е: Колко има в кофата ви? Това е: Колко голяма е вашата кофа?

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

КАКВО Е НАЛИЧНО?

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

Ако посетите сайта на Amazon Web Services (AWS) и потърсите цените, ще забележите, че те определят цените поне отчасти въз основа на идеята за ECU (EC2 Compute Unit). На някакво ниво това е самореферентна стойност, представляваща относителния изчислителен капацитет на всяко от техните предложения. 26 означава, че такова предложение има приблизително два пъти по-голям капацитет от 13. Само с това знание обаче осъзнавате, че нямате представа какво представлява 13. Ако копаете по-нататък, научавате, че едно ECU представлява изчислителния капацитет на едно и конкретно процесорно ядро ​​с конкретен цикъл; на тази референтна система ще бъде присвоена стойност 1. ECU грубо представя капацитета за производителност, наличен в ядрото на процесора, макар и на определено по-старо ядро. Това е стабилна, непроменяща се мярка за капацитет, извършваща някаква комбинация от работа на този процесор. Добре, това може да помогне, но все още не е задължително да имате препратка към вашия свят. Искам да кажа, колко от вашите собствени транзакции/минута бихте могли да произведете с ECU дори 1?

Оценките като 13 или 26 – или каквото имате – се определят чрез множество бенчмаркове и магически тестове за производителност, изпълнявани на въпросната хардуерна среда, с резултати в сравнение с референтната система. Хората от Amazon знаят много добре, че има много различни начини за използване на тези системи и техните работни среди примерни за някои от тях. Моля, имайте предвид обаче, че сред тях може да има значителни относителни вариации от натоварване до натоварване и дори повече, когато преминаваме от система към система. Както се казва, "Вашите резултати може да варират." Тези рейтинги на ECU са резултат от комбинация от избраните работни натоварвания; всяко едно от натоварванията може или не може да произведе два пъти по-голяма производителност на 26 спрямо 13. Така че те използват смес; те биха могли да публикуват всичките си резултати, но ние всички искаме бърза справка за относителен капацитет като ECU. Все пак това е добър подход, ако това, което търсите, е представяне на относителния капацитет с едно число.

Малко обяснение по-нататък: Дори да използвате едно ядро, има много начини, по които може да се постигне даден рейтинг; чрез хардуерна технология, време на цикъл, фин паралелизъм, размер на кеша и топология, честотна лента на шината, скорост на паметта и т.н. Можем също грубо да удвоим капацитета от 13 на 26 чрез удвояване на броя на ядрата. Отново такива разлики в дизайна може да означават разлики в производителността на специфични работни натоварвания.

Това е AWS. Други системи се опитват да представят своя системен капацитет, използвайки други концептуално подобни оценки. (Като пример, от моя собствен опит в IBM Power Systems, има CPW, съкращение от Commercial Performance Workload и базирано на теста за онлайн обработка на транзакции TPC-C.) Някои предлагат значително по-фина детайлност на капацитета на вашето копие. И това е, което купувате, капацитетът на екземпляр на ОС, обикновено част от капацитета на един цял SMP. Така че въпросът е: Това, което наистина получавате с ECU, е изявление за частта от общия наличен капацитет в рамките на някаква по-голяма физическа SMP система. Екземплярът на ОС, който купувате, споделя същия хардуер – поне за известно време – с известен брой други екземпляри; всеки получава някаква част от този общ капацитет. Както споменахме, работата на облачната услуга е отчасти да определи как най-добре да ги опакова заедно, като се имат предвид изискванията за капацитет на всеки такъв екземпляр.

Различен от ECU, AWS има друг показател, който нарича vCPU, съкращение от виртуален процесор. Други имат свързани концепции като VP (виртуален процесор). Ще използвам двата термина взаимозаменяемо. Това също е абстрактно понятие. Това, което не е, е някакво конкретно ядро ​​в рамките на SMP, което екземплярът на вашата операционна система съхранява за неопределено време. Вместо това всеки VP е абстрактен обект, на който ОС възлага работа (известна още като работа като задача или нишка). Когато се установи, че VP на вашата операционна система има изпратена работа към него, този VP впоследствие се присвоява на ядро ​​за известен период от време. Разликата може да изглежда фина на този етап, но тя е важна за ефективността по начини, които ще разгледаме скоро. VP не е ядро, това е абстракция на процесор.

Така че, когато казвате, че вашият екземпляр на ОС има – да речем – четири vCPU, това, което всъщност казвате, е, че вашата ОС знае за четири обекта, към които може да изпраща задачи. Това не означава, че вашата операционна система в този момент има четири конкретни ядра – и капацитета, който те представляват – върху които вашите задачи могат да изпълняват своите потоци от инструкции. Вместо това vCPU представлява максимално възможно ниво на SMP процесорен паралелизъм. Рейтинг на vCPU четири означава, че една операционна система може да има четири пъти повече едновременно изпълнявани задачи, отколкото е възможно с операционна система с vCPU брой едно.

По някакъв начин броят на VP също представлява максимален капацитет, тъй като операционна система с четири VP е ограничена до този брой едновременно и непрекъснато изпълняващи се задачи; не получавате повече пропускателна способност от наличната, работейки постоянно с четири VP, точно както не получавате повече, отколкото ако работите непрекъснато на четири ядра. Ако нямаше представа за ECU и само броене на vCPU за представяне на капацитет, стойност на vCPU от четири означава, че имате до капацитет от четири едновременно изпълняващи се задачи, ако се изпълняват непрекъснато. След това стойността на капацитета на ECU става ограничение на капацитета, по-малко от този базиран на vCPU максимум.

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

В заключение на този раздел бяха очертани две концепции:

Можете да наемете изчислителен капацитет, представляващ част от общия изчислителен капацитет на отделно SMP.

Можете да укажете нивото на SMP паралелизъм; колко задачи могат да се изпълняват едновременно.

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

КАКВО Е ПРОЦЕСОР?

Преди термините – процесор или процесор – се разбираха доста добре. Но както хардуерните, така и софтуерните промени направиха и двете доста недефинирани и често злоупотребявани. Помислете за SMT (едновременна многонишкова обработка) или приблизително аналогичната Hyper-Threading на Intel. И в двата случая по-добре дефинираното понятие за процесорно ядро ​​е активирано, за да му позволи едновременно да изпълнява множество потоци от инструкции. Вместо задачи/нишки да се изпращат една към една към процесорните ядра, тези ядра могат да се разглеждат като едновременно изпълняващи инструкции от името на множество нишки.

Така че защо повдигате това в дискусия за виртуализация? Отговорете на това: Какво е VP или vCPU? Дали VP е ядро ​​с всички негови SMT хардуерни нишки заедно, или VP е единична хардуерна нишка, една от множеството в едно ядро? В последния, VP представлява изпълнението на единичен поток от инструкции; в първия, VP представлява потоците от инструкции на множество задачи.

Като се има предвид, че няма разлика в производителността, въпросът може да се счита за спорен. Но разлика има и тя е доста съществена.

Като предимно концептуален пример, помислете за следното, взето от фигура, представяща увеличената производителност на процесор Power8 при наличие на до осем нишки на ядро. От гледна точка на общата пропускателна способност, всяко ядро ​​има значително по-голям капацитет – по-голям потенциал за пропускателна способност – поради 8-way SMT (a.k.a., SMT8); едно Power8 ядро ​​може да поддържа до 8 нишки. Този допълнителен капацитет е нещо добро. Но също така забележете пропускателната способност на референтна нишка – да речем, тази в синьо – тъй като тя първо започва сама на ядро ​​(т.е. лентата вляво) и след това споделя същото ядро ​​с едно, след това три, след това седем други нишки. Индивидуалната пропускателна способност на тази нишка намалява значително. Това е напълно нормално поведение; всяка нишка може да е по-бавна, но поради SMT поне се изпълнява; същата нишка няма да има пропускателна способност през времето, в което чака „SMT нишка“, ако такава SMT възможност не съществува.

power8-threading

И така, защо този урок? Помните ли въпроса? Дали vCPU е свързан с пълно ядро ​​– тук може да поддържа до 8 нишки – или vCPU е свързан с една SMT нишка – една от до осем на всяко ядро? Ако последното, тогава физическото ядро ​​също поддържа множество vCPU; припомнете си отново, че когато дефинирате нов екземпляр на ОС, вие също така дефинирате максималния брой VP/vCPU, които възнамерявате да използвате. Така че, ако сте посочили две VP, достигате ли капацитета на две ядра или на две SMT нишки?

Засега да кажем, че vCPU е SMT хардуерна нишка, а не пълно ядро ​​(с множество SMT нишки). Да предположим също, че имате екземпляр на ОС с два vCPU и на двата са възложени задачи, което означава, че и двата искат да бъдат присвоени на „процесор“. Напълно възможно е vCPU на вашата операционна система да бъдат присвоени на различни ядра и нито един vCPU на друга операционна система в този момент не споделя ядрата. Страхотен. Вашите задачи са да използвате пълните ресурси на тези ядра и в резултат на това да се изпълнявате възможно най-бързо. Или, да речем, vCPU на вашата операционна система могат да бъдат присвоени на едно и също ядро. Добре, ако са сами заедно, и двамата се изпълняват, но всеки по-бавно, отколкото в предишния случай.

Но облакът всъщност не е само изпълнение в SMP; има други операционни системи с техните vCPU, които споделят същата система. Така че нека увеличим използването на системите и другите операционни системи също да бъдат заети. Къде са разпределени техните vCPU? Разбира се, те биха могли временно да бъдат присвоени на различни ядра, но техният vCPU може да бъде присвоен(и) към същото(и) ядро(я), където един или повече от vCPU на вашата операционна система са присвоени в този момент. В сравнение с изпълнението самостоятелно на ядро, тъй като използването на системата се увеличава, има повишена вероятност вашите vCPU(и) да споделят ядра и така да работят относително по-бавно.

Иначе казано, да предположим, че вашата операционна система има само един vCPU – и следователно само една нишка – активна в момента. Може да очаквате, че тази нишка трябва да се изпълнява напълно точно като синята нишка в най-лявата колона по-горе. Наистина може многократно да сте изпитвали този ефект и да не сте го знаели; системата беше леко използвана и това беше резултатът. Така че нека – без да знае нишката за приложения на тази операционна система – да увеличим използването на всички други операционни системи и vCPU на същия SMP. Вашата нишка все още ще може да използва „процесор“, но сега много по-често споделя ядро ​​с редица други активни vCPU. Резултатът е по-бавно изпълнение. И поради очакваната функционална изолация на операционните системи, няма нищо във вашите операционни системи, което да може да ви каже защо производителността на приложението се е забавила.

Разбира се, проблемът е по-малко интензивен с максимум само две нишки на ядро, но основната концепция остава.

И така, vCPU ядро ​​ли е или SMT нишка? За ESXi хипервайзора на VMware: „Като се има предвид, че 1 vCPU е равен на 1 CPU, това е предположение с цел опростяване, тъй като vCPU са планирани на логически CPU, които са контексти на хардуерно изпълнение. Тези задачи могат да отнемат известно време в случай на едноядрен процесор, процесори, които имат само 1 нишка на ядро, или могат да бъдат само нишка в случай на процесор, който има хипер-нишки.

VCPU с ESXi хипервайзор на VMware е SMT нишка. С PowerVM хипервайзора на IBM понятието виртуален процесор (т.е. VP) е различно; VP е свързан с физическо процесорно ядро, включително наведнъж всички SMT нишки на ядрото. VP тук не е непременно обвързано с конкретно ядро; диспечерът на задачите на операционната система присвоява една или повече задачи на VP – сякаш е физическо ядро ​​– и след това хипервайзорът присвоява VP на налично ядро, освобождавайки динамично ядро, ако е необходимо.

Виждате ли разликата между VMware ESXi и IBM PowerVM? С PowerVM все още е вярно, че едно ядро ​​може едновременно да изпълнява една или няколко нишки. Но ако множество нишки, с PowerVM, всички нишки, изпълнявани на някое ядро, принадлежат към една и съща ОС. Ако, да речем, използването на вашата операционна система е било достатъчно ниско, за да има само една нишка на VP, тези нишки ще се изпълняват самостоятелно и следователно по-бързо, когато всяка VP също е прикрепена към ядро. С VMware, дори ако вашата операционна система има точно една изпълняваща нишка – тази нишка е свързана сама с vCPU – възможно е тази нишка да се окаже споделяща ядро ​​с vCPU(и) на други операционни системи; увеличеното използване, възникващо в други операционни системи, може да забави производителността на други операционни системи.

Но и с PowerVM не всичко е идеално. Ако VP е активен дори с една нишка, хипервайзорът присвоява този VP на ядро. Целият капацитет на ядрото се използва от това присвояване; никой друг вицепрезидент не може да го използва тогава, въпреки че там се изпълнява само една нишка. Както видяхте на SMT фигурата по-горе, при изпълнение на една нишка всъщност има доста наличен капацитет, но при този подход той трябва да остане неизползван. След това целият капацитет на ядрото трябва да се отчете като използван. VMware, третирайки всяка SMT нишка като че ли е просто друг физически процесор, вместо това ще присвои vCPU (т.е. винаги една нишка) към всяка налична SMT нишка в рамките на което и да е ядро. Въпросът тук е, че при подхода на PowerVM, тъй като част от капацитета може да остане неизползван в ядрото, нишките на други операционни системи, които биха могли да използват този капацитет, вместо това чакат своя ред за налично ядро. (Интересното е, че знам за поне една PowerVM OS – и може би повече – която се опитва да опакова нишки в VP до определен момент, за да намали този ефект.)

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