Ahoj, pripojim se do teto diskuse, protoze doufam, ze k tomu mam co rict, i kdyz predesilam, ze s virtualizaci na FreeBSD jsem zatim neexperimentoval a to ani s VirtualBoxem, ani s bhyve, ktere mi pripada z pohledu vykonu a provozu produkcnich workloadu zajimavejsi, jelikoz se jedna o virtualizaci Typu 1 a nikoliv Typu 2, jako je VirtualBox.
<snip> There are two main hypervisor types, referred to as “Type 1” (or “bare metal”) and “Type 2” (or “hosted”). A type 1 hypervisor acts like a lightweight operating system and runs directly on the host’s hardware, while a type 2 hypervisor runs as a software layer on an operating system, like other computer programs. </snip> Duvodem, proc jsem zatim neexperimentoval s virtualizaci na FreeBSD je to, ze se od roku 2006 intenzivne venuji virtualizaci pomoci technologii VMware a zivim se tim :-) DISCLAIMER: jsem zamestnancem VMware, takze muj nazor tim muze byt ovlivnen. Na druhou stranu jsem dlouletym uzivatelem FreeBSD a povazuji ho za jeden z nejlepsich OS se skvelou minulosti i budoucnosti. Musim otevrene rict, ze mam pocit, ze pomalu nastava cas zacit testovat bhyve, protoze i kdyz je porad velky rozdil v detailech mezi ruznymi hypervizory, tak na spoustu veci uz dnes bohate staci i open-source technologie. Na testovani bhyve se chystam ve verzi FreeBSD 13. Nicmene zpatky k tematu. Pozorovany symptom subjektivne lepsiho vykonu s mene vCPU nez s vice vCPU neni nic neobvykleho ani na jinych virtualizacnich platformach, a dokonce i na roky vyladenem VMware hypervizoru (ESXi), ktery se dnes pouziva i pro business critical workloady. Rikam tomu "VIRTUALIZATION PARADOX". Problematiku jsem pred 7-mi lety popisoval zde https://www.vcdx200.com/2013/10/two-2-or-four-4-socket-servers-for.html Upozornuji, ze v te dobe byly 8-mi vCPU virtualni servery brany jako "monster" VM, coz je z dnesniho pohledu usmevne, ale princip je porad stejny. V dnesni dobe ja osobne povazuji za "monster" VM virtualni servery od 32 vCPU a 256 GB RAM vyse, ale takove virtualni servery typicky bezi na hardwaru, ktery je popsan zde https://www.vcdx200.com/2021/01/server-rack-design-and-capacity-planning.html Takze co je to tedy "VIRTUALIZATION PARADOX"? "VIRTUALIZATION PARADOX" je situace, kdy konkretni vypocetni workload bezi lepe na virtualnim serveru s mene vCPU nez na stroji s vice vCPU. <snip from="https://www.vcdx200.com/2013/10/two-2-or-four-4-socket-servers-for.html";> In our example we are planning to have monster VMs with 8 vCPUs so 64 logical CPUs in 4S-SERVER offers potentially more scheduling opportunities against 32 logical CPUs in 2S-SERVER. As far as I know virtualization benchmarks tiles (tiles are a group of VMs) usually have up to 2 vCPUs so I think the co-scheduling issue is not covered by these benchmarks. So the final decision depends on the expected number of monster VMs which can affect real performance of workloads inside these monster VMs. CPU performance overloading can be monitored by ESX metric %RDY (vCPU READY but pCPU not) and co-scheduling execution delays by metric %CSTP (vCPU stopped because of co-scheduling). Recommended thresholds are discussed here but every environment has different quality requirements so your thresholds can be different and it depends what quality SLA you want to offer and what type of application you want to run on top of virtual infrastructure. Anyway, co-scheduling of monster VMs is a serious issue for IaaS Cloud Providers because it is really hard to explain to customers that less vCPUs can give them paradoxically better CPU performance. I call this phenomenon "VIRTUALIZATION PARADOX". </snip> Nechci jit do uplneho detailu, ale problematika je spojena s CPU schedulingem. V tom je totiz rozdil mezi General Purpose OS (FreeBSD, Linux, etc.) a bare metal hypervizor (VMware ESXi). Hypervizor je samozrejme take Operacni System, ale ma jednotlive schedulery (CPU, RAM, Storage, Network) vyladeny pro specificky ucel, a tim je provoz virtualnich serveru. Jinymi slovy scheduling. Koncepcne je "VIRTUALIZATION PARADOX" o tom, ze hypervizor scheduler ma k dispozici napr. 24 CPU Cores (pCPU), ktere se pomoci hyperthreadingu mohou zdvojnásobit na 48 CPU Threads - logickych CPU (lCPU). Cilem serverove virtualizace je partitioning a sharing resourcu, takze se zavadi pojem vCPU (virtualni CPU), coz neni nic jineho nez proces emulujici CPU. Tyto vCPU jsou pak schedulovany na logicke CPU (lCPU). Mam-li tedy scheduler k dispozici 48 logickych CPU, tak se na tom celkem v pohode uprovozuje 6x 4vCPU Virtual Machine, protoze se scheduluje 24 vCPU na 24 pCPU a hyperthreding dava systemu k dispozici az 48 lCPU, ktere davaji prostor schedulovat i systemovy overhead spojeny s virtualizaci (overhead). V takovemto pripade bych tedy neocekaval vykonnostni problemy a User eXperience by nemela byt virtualizaci vubec postizena. Jelikoz je virtualizace nejen o partitioningu, ale i o sharingu, tak toto vetsinou uzivatelum nestaci a chteji vic, takze se pokracuje k tzv. overbookingu. Ve vyse uvedenem scenari s 24 pCPU systemem, si dokazu predstavit, a v praxi se realne pouziva, provoz 18-ti 4vCPU Virtual Machine, jelikoz pri provozu 72 vCPU na 48 lCPU dochazi k akceptovatelnemu frontovani (queueingu) vCPU v ramci CPU scheduleru (logical CPU). Akceptovatelne frontovani vCPU versus pCPU je velmi subjektivni a relativni pojem. Kazda aplikace je jinak nachylna na CPU latency, a je logicke, ze vyssi vCPU / pCPU pomery vedou k vetsi pravdepodobnosti toho, ze vCPU bude cekat delsi dobu v CPU scheduler queue, a tim se muze zvysit CPU latence uvnitr virtualizovaneho serveru. Ve virtualizacnim svete se provozuji nasledujici typicke virtualizacni pomery vCPU : pCPU 1 : 1 - mission critical aplikacni workloady (CPU latency sensitive) 3 : 1 - business critical aplikacni workloady 5 : 1 - general aplikacni workloady 10 : 1 - testovaci nebo nekriticke workloady (CPU latency nonsensitive) pCPU je ve vyse uvedenych pomerech CPU Core, nikoliv CPU thread (logicke CPU). Pozor! Ve vsech vyse uvedeny uvahach vychazim z virtualizace Typu 1, coz VirtualBox neni. Pri pouziti VirtualBoxu je potreba pocitat s vetsim overheadem virtualizace a navic i s workloadem, ktery musi uprovozovat podkladovy Operacni System pro nevirtualizovany aplikacni workload. A dalsi pozor! Zatim jsem naznacil jen frontovani vCPU na CPU Scheduleru, ale jelikoz se bavime o schedulingu virtualnich serveru s vice vCPU, tak tam je jeste dalsi slozitost, protoze hypervisor musi mit implementovane vSMP (virtualni symetricky multiprocesing) a tam je zasadni jestli se scheduluji vsechny VM vCPU do CPU scheduleru najednou (a pri takovemto pristupu se muze vCPU latence dost zvysit) a nebo je umoznen scheduling vCPU i jednotlive (tak to delaji moderni hypervizory). Nicmene, kdyz hypervizor vSMP umoznuje scheduling jednotlivych vCPU, tak se muze stat, ze se jednotlive vCPU v ramci jedne VM casove rozjedou, a kdyz uz je to moc, tak je potreba aby ty vCPU, ktere jsou moc v prestihu, pockaly na vCPU, ktere jsou casove pozadu. A tomu se rika CO-STOP (co-scheduling stop). Viz. https://vmware2112.wordpress.com/2012/07/05/what-does-the-cpu-co-stop-counter-measure-cstp/ Takze jak vidite, tak velmi zalezi na implementaci jednotlivych hypervizoru, ale na to uzivatele vetsinou prijdou az tehdy, kdyz pozoruji vykonnostni problemy. Vitejte ve svete serverove virtualizace, kde se snazime oklamat fyziku a ono to nekdy trosku funguje a nekdy uz proste ne ;-) David. -- David Pasek [email protected], +420 602 525 736 -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
