Parengtas procesorius: tylus hipervizoriaus žudikas

Parengtas procesorius yra kažkas, ko galbūt nežinote. Iš pirmo žvilgsnio tai gali atrodyti gerai, bet, deja, taip nėra. „CPU Ready“ virtualią aplinką kankina ilgiau nei žinojome, kas tai yra. „VMware“ tai apibrėžia kaip „laiko, kurį virtuali mašina buvo parengta, bet nepavyko suplanuoti veikti fiziniu procesoriumi, procentas. Centrinio procesoriaus parengties laikas priklauso nuo virtualiųjų mašinų skaičiaus pagrindiniame kompiuteryje ir jų procesoriaus apkrovos. “ „Hyper-V“ tik neseniai pradėjo teikti šį skaitiklį („Hyper-V Hypervisor“ virtualus procesorius CPU laukimo laikas per išsiuntimą), o kiti hipervizoriai vis tiek gali nepateikti šios metrikos.

Norėdami suprasti, kas yra pasirengęs procesorius, turime suprasti, kaip hipervizoriai planuoja virtualius procesorius (vCPU) į fizinius procesorius (pCPU). Kai reikia VCPU laiko VM, tai vCPU (-us) reikia suplanuoti pagal pCPU (-us), kad komandos / procesai / gijos galėtų veikti prieš pCPU. Idealiame pasaulyje nėra išteklių konfliktų ar kliūčių, kai tai turi įvykti. Kai vienam vCPU VM reikia planuoti laiką, palyginti su pCPU, yra prieinamas pCPU branduolys, o šiame idealiame pasaulyje CPU parengtis yra labai minimali. Svarbu pažymėti, kad „CPU Ready“ visada egzistuoja, tačiau idealiame pasaulyje jis yra labai minimalus ir nepastebimas.

Realiame pasaulyje vienas iš virtualizavimo pranašumų yra tas, kad galite lažintis, kad daugelis jūsų VM vienu metu nepadidins visų savo vCPU ir, jei jie yra labai mažai naudojami VM, galite net atspėti, kiek galite įkelkite savo fizinį pagrindinį kompiuterį pagal procesoriaus ir RAM naudojimą. Anksčiau, atsižvelgiant į darbo krūvį, buvo pateiktos rekomendacijos turėti 4 vCPU ir 1 pCPU arba net 10: 1 santykį. Pvz., Galite turėti vieną keturių branduolių procesorių, bet turite 4 VM su vCPU, kad gautumėte 16 vCPU iki 4 pCPU arba 4: 1. Vis dėlto inžinieriai pradėjo matyti tai, kad aplinka buvo tiesiog siaubingai lėta ir jie negalėjo suprasti, kodėl. RAM naudojimas atrodė gerai, procesorių naudojimas fiziniuose pagrindiniuose kompiuteriuose gali būti net labai mažas, nesiekia 20%. Saugyklos vėlavimas buvo labai mažas, tačiau VM buvo labai vangus.

Tai, kas vyko šiame scenarijuje, buvo paruoštas procesoriui. Parengta suplanuoti vCPU susidarė eilė, tačiau nebuvo galima planuoti pCPU. Hipervizorius sustabdytų planavimą ir sukeltų svečio VM vėlavimą. Tai tylus žudikas, kurį iki pastarųjų metų nebuvo daug priemonių aptikti. „Windows VM“ įkrovimas užtruktų amžinai, o kai pagaliau tai padarys, kai spustelėsite meniu Pradėti, jis pasirodys amžinai. Galite net spustelėti dar kartą manydami, kad jis nepriėmė jūsų pirmojo paspaudimo, o kai jis pagaliau pasivys, gausite dvigubą paspaudimą. „Linux“ sistemoje jūsų VM gali paleisti tik skaitymo režimą arba net tam tikru momentu perjungti failų sistemas į tik skaitymo režimą.

Taigi, kaip mes kovojame su pasirengusiu procesoriumi? Yra keli būdai, kurie gali padėti. Pirmasis yra procesoriaus parengties metrikos stebėjimas. „VMware“ nerekomenduojama viršyti 10%, tačiau, atsižvelgiant į asmeninę patirtį, vartotojai pradeda pastebėti daugiau nei 5–7%, priklausomai nuo VM tipo ir to, ką jis veikia.

Žemiau aš naudosiu keletą pavyzdžių iš „VMware ESXi 5.5“ norėdamas parodyti paruoštą procesorių. Naudodami komandinę eilutę, paleiskite „esxtop“. Norėdami pamatyti procesoriaus rodinį, paspauskite „c“ ir turėtumėte pamatyti stulpelį „ % RDY Parengta procesoriui. Galite paspausti kapitalą “ V Tik VM rodinys.

Čia galite pamatyti, kad% RDY yra šiek tiek didelis gana nenaudojamoje aplinkoje. Šiuo atveju mano „ESXi 5.5“ veikia bandomasis VM ant „VMware Fusion“ („Mac hypervisor“), todėl tikimasi, kad jis bus šiek tiek aukščiausias, nes VM paleidžiame ant hipervizoriaus ant kito hipervizoriaus.

„VSphere“ kliente galite pasirinkti konkretų VM ir spustelėti skirtuką „Našumas“. Iš ten spustelėkite „Diagramos parinktys“

Diagramos parinktyse pasirinkite „CPU“, „Real-time“ (jei turite „vCenter“, galite turėti kitas laiko parinktis nei realiuoju laiku). Iš ten „Counters“ pasirinkite „Ready“. Jums gali tekti panaikinti kito skaitiklio pasirinkimą, nes rodinyje bet kuriuo metu leidžiama naudoti tik du duomenų tipus.

Atkreipkite dėmesį, kad ši vertė yra parengties ir procentų apibendrinimas. Čia yra nuoroda į „VMware KB“ straipsnį, kaip konvertuoti apibendrintą metriką į procentą. - https://kb.vmware.com/kb/2002181

Perkant aparatinę įrangą, daugiau branduolių padeda sumažinti procesoriaus parengties poveikį. Padeda ir hipersriegimas. Nors „Hyperthreading“ nepateikia pilno antrojo branduolio kiekvienam pagrindiniam branduoliui, paprastai pakanka leisti planuoti vCPU į pCPU ir padėti sušvelninti problemą. Nors hipervizoriai pradeda atsisakyti vCPU prie pCPU santykio rekomendacijos, paprastai galite gerai elgtis vidutiniškai naudojamoje aplinkoje 4: 1 ir eiti iš ten. Pradėdami krauti VM, peržiūrėkite procesoriaus vėlavimą, pasirengimą procesoriui ir bendrą savijautą bei našumą. Jei turite daug pataikiusių VM, galbūt norėsite juos išskirti į kitas grupes ir naudoti mažesnį santykį ir išlaikyti juos lengvus. Kita vertus, VM, kur našumas nėra pagrindinis dalykas ir jiems gerai veikti vangiai, galite užsisakyti daug didesnę.

Tinkamas VM dydžio nustatymas taip pat yra didžiulė priemonė kovojant su paruoštu procesoriumi. Daugelis pardavėjų rekomenduoja specifikacijas, palyginti su tuo, ko VM iš tikrųjų gali prireikti. Tradiciškai daugiau procesorių ir daugiau branduolių = daugiau galios. Virtualioje aplinkoje problema yra ta, kad hipervizorius turi suplanuoti visus vCPU į pCPU maždaug tuo pačiu metu, o pCPU blokavimas gali būti problemiškas. Jei turite 8 „vCPU“ VM, turite užrakinti 8 „PCCU“, kad leistumėte jiems planuoti tuo pačiu metu. Jei jūsų vCPU VM naudoja tik 10% visų vCPU bet kuriuo metu, jums geriau sumažinti vCPU skaičių iki 2 arba 4. Geriau paleisti VM 50-80% procesoriumi, kuriame mažiau nei 10% daugiau „vCPU“. Ši problema iš dalies yra dėl to, kad operacinės sistemos procesoriaus planuoklis sukurtas naudoti kuo daugiau branduolių, tuo tarpu jei jis būtų išmokytas maksimaliai išnaudoti branduolius prieš naudojant daugiau, tai gali būti mažiau problema. Negabaritinis VM gali veikti gerai, bet gali būti „triukšmingas kaimynas“ kitiems VM, todėl paprastai tai yra procesas, kai jūs turite pereiti visus klasterio VM į „tinkamo dydžio“, kad pamatytumėte tam tikrą našumą.

Daug kartų susidūrėte su paruoštu procesoriumi ir sunku pradėti teisingai nustatyti VM dydį arba naujovinti į procesorius, turinčius daugiau branduolių. Jei esate tokioje situacijoje, galite pridėti daugiau kompiuterių į savo grupę, kad tai padėtų paskirstyti apkrovą daugiau kompiuterių. Jei turite pagrindinius kompiuterius su daugiau branduolių / procesorių nei kiti, taip pat gali padėti aukštų vCPU VM susiejimas su šiais aukštesnio lygio pagrindiniais kompiuteriais. Norite užtikrinti, kad jūsų fiziniame pagrindiniame kompiuteryje būtų bent tas pats branduolių skaičius, jei ne daugiau nei VM, kitaip bus labai lėta / sunku suplanuoti vCPU perteklių į pCPU, nes juos reikia užrakinti maždaug tuo pačiu metu .

Galiausiai jūsų hipervizorius gali paremti VM išlygas ir apribojimus. Kartais tezės nustatomos netyčia. Dėl agresyvių šių parametrų CPU gali būti parengtas, nors iš tikrųjų jam yra prieinami pagrindiniai ištekliai. Paprastai geriausia rezervacijas ir apribojimus naudoti taupiai ir tik tada, kai to tikrai reikia. Daugeliu atveju tinkamo dydžio klasteris tinkamai subalansuos išteklius ir jų paprastai nereikia.

Apibendrinant galima pasakyti, kad geriausia apsauga nuo „CPU Ready“ yra žinojimas, kad jis egzistuoja ir kaip jį patikrinti. Tada, atsižvelgiant į tai, kas išdėstyta pirmiau, galite sistemingai nustatyti geriausius aplinkos mažinimo veiksmus. Šio straipsnio informacija dažniausiai taikoma visiems hipervizoriams, nors ekrano kopijos ir diagramos taikomos būtent „VMware“.