cim vic jader CPU, tim pomalejsi

[David Pasek]

Ahoj,
trochu jsem doufal, ze se tady k teto probelmatice dozvim neco noveho
a deje se tak, takze ja jsem spokojeny.
A take je super, ze se zapojuji ostatni, protoze toto je vec, ke ktere
drive ci pozdeji dospeje kazdy kdo virtualizuje servery.

On Tue, Apr 6, 2021 at 3:19 PM Zdenek Havrlik <zdenek at lhotkanet.cz> wrote:
>
> Nedavno jsme v praci na VMWare resili takovou vec ktera se jmenuje
> "co-stop".   Chovani vsak  je podobne cim vice CPU tim mensi vykon.

Zaznelo to, ale mozna jsem kolem toho napsal zbytecne moc textu a tak
to zapadlo.
Presne to je ten VIRTUALIZATION PARADOX, o kterem jsem psal a je to
spojene s CPU schedulingem a primarne s virtual SMP (vSMP), tzn.
schedulingem skupin vCPU jedne VM na fyzicke pCPU v ramci hypervizor
hosta (napr. ESXi).

VMware metrika CO-STOP je prave ta ESXi metrika, ktera monitoruje
umele zpozdovani urcite podmnoziny vCPU jednoho VM-ka, kdy ty vCPU
maji diky "relaxed co-schedulingu" moc velky predstih (aka "CPU skew")
pred ostatnimi vCPU. V ramci "Strict Co-schedulingu" by se nic
takoveho nedelo, ale ukazuje se, ze strict co-scheduling neumoznuje
vyssi overbooking vCPU:pCPU. "Relaxed co-scheduling" vsak zase
vyzaduje znacne slozitejsi implementaci vSMP, takze to nebyvalo
implementovana v open-source hypervizorech. V tom dokumentu co nasel
Dan je napsane, ze KVM a Virtual Box pouzivaji prave ten naivni
"Strict Co-scheduling. Ten dokument je vsak z roku 2013, coz uz je
zase 7 let, za ktere se mohlo spousta veci zmenit. Nejvice me osobne
zajima prave ten BHYVE, ktery pred 7-mi lety byl, jestli se nepletu,
teprve releasovan v ramci FreeBSD 8.4 (7 June 2013). Do budoucna na
nej hodne sazim ;-)

> Shrnuto:
>
> 1.  Vm nesmi mit vice CPU nez jeden fyzicky procesor kuli NUMA.

S timto bych nesouhlasil, i kdyz uznavam, ze je to nejlepsi, kdyz si
to mohu dovolit. Nakonec je to vzdy o pomeru cena/vykon ;-)

Navic nejsem ani presvedcen, ze NUMA nutne souvisi s VIRTUALIZATION
PARADOXem, ktery tady ted diskutujeme. Kazdopadne je mozne hypervizor
a VM systemy nadesignovat tak, aby se pouzivala vNUMA (virtual NUMA).
NUMA je ale obecne o pristupu k pameti RAM, takze o latency pristupu k
lokalni a vzdalene pameti v Non-Uniform systemech. Pristup k lokalni
RAM je cca 80 ns, a pristup ke vzdalene RAM je cca 120 ns, a jeste
navic je tam riziko ze CPU interconnect mezi NUMA nody je zaplnen, coz
muze RAM latency jeste vice zhorsit.

> 2.  Pokud na hostiteli bezi nekolik VM masin, napriklad 5 kousku, kde
> VMka maji po treba 4 vCPU a fycicke CPU ma 16 core, mohou se na na
> procesoru stridat casteji a nektere vytizene ho ani nemusi opoustet.

Opousti se vzdy, zalezi jen na tom kdy. Je to vlastne implementace CPU
Time-division Multiplexingu, takze po urcite dobe se musi vCPU
deschedulovat.
vCPU tudiz nemuze byt schedulovano na pCPU nekonecne dlouho. U ESXi
scheduleru je ten maximalni cas pro vCPU dany konstantou, ale zaroven
je mozne ovlivnit jak dlouho muze vCPU bezet na pCPU. Resi se to
pomoci konceptu "shares" (akcii) implementujici "The
proportional-share based scheduling", takze se muze ovlivnovat kdo ma
vetsi prioritu, ale jinak nez se resi prioritizace procesu v klasickem
UNIX-like scheduleru.
Ted jsem dohledal dokument s vice informacemi, kde je to hezky popsane
- https://www.dihe.de/docs/docs/perf-vsphere-cpu_scheduler.pdf
A tady v tom blog postu je to taky pekne zrekapitulovane -
https://kloudkonnect.wordpress.com/2019/08/23/understanding-esxi-cpu-scheduling/

>
> Pokud vsak k temto VM pridam dalsi byt treba nevytizene VM s 16vCPU, mam
> problem,  hostitel musi zastavit vsechny ostatni VM a na procesoru
> pustit prave  pouze to jedno 16corove VM.  Pricemz ta rezie a
> synchronizace zastaveni vsech VM neni zadarmo.

Takto naivne to na VMware prave nefunguje. Takto se to chova ve
"Strict Co-schedulingu", kteremu se v tom paperu, ktery nasel Dan rika
trefne "naive". Ve VMware Hypervizoru (ESXi) je to slozitejsi a nemusi
se schedulovat vsechna vCPU jednoho VM-ka ve stejnou dobu.

Ale prave v tomto komnkretnim pripade muzes pozorovat prave ten
PARADOX, ze ta 16 vCPU VM ma horsi performance nez VM-ka s mensim
poctem vCPU, a ze kdyz odeberes tomu 16vCPU VMku vCPU, tak se zlepsi
vykon i pro to "monster" VM-ko.

V pridelovani CPU zdroju na VMware Hypervizoru (ESXi) hrajou roli i
pripadna nastaveni CPU SHARES a RESOURCE POOLS, kterymi se ridi vCPU
to pCPU scheduling, ale vetsina VMware zakazniku nevi jak to presne
funguje, takze to bud nepouzivaji a nebo si k tomu objednavaji experty
;-)
Ale fyziku osalis jen trosku, nejde to do nekonecna. Ani "expert"
neudela zazraky ;-)

Dneska jsem to zrovna jednomu zakaznikovi detailne vysvetloval a
ukazoval na konkretnich metrikach z jeho prostredi. K dukazu techto
hypotez vsak potrebujes kvalitni monitoring system, ktery nastesti
zakaznik mel, protoze ma od VMwaru cely stack. Sber takovych metrik v
case a velikosti prostredi se 150 ESXi servery a 3000 VM-kama je totiz
big data problem, takze neni trivialni ta data zanalyzovat  ;-)

>
> To muze delat problemy.

Ano. To muze, a taky to obcas problemy dela.
To je prave duvod, proc napr. Solaris (Sun Microsystems, dnes Oracle),
dej mu panbuh lehkou zem, nikdy zadny ovebooking (overcommitment)
zdroju nedelal ani pro kontajnerizaci (Zones), protoze se to
neslucovalo s jejich pojetim Enterprise. Chapu to tak, ze Virtual Box
(taky Oracle), se k tomu stavi stejne jako Solaris, a proto je ve
VirtualBox dokumentaci napsano, ze doporucuji vCPU <= pCPU. VMware se
k tomu od svych zacatku (rok 1998) stavi tak, aby umoznoval
overbooking, coz je stejny princip, ktery se roky pouziva treba na
Ethernet/IP sitich a pamatuju si telko lidi, kteri rikali, ze pres
switchovane site se telefonovat nikdy nebude :-) Rozhodnuti jak hodne
systemy overbookovat VMware nechava na provozovatelich systemu. Coz je
trosku problem, kdyz mi nekdo provozuje server v cloudu, snazi se na
tom co nejvice vydelat a neresi kvalitu poskytovane sluzby. Konzument
sluzby (zakaznik) si pak muysi umet kvalitu dodavane sluzby
monitorovat a podle toho se umet rozhodnout, jestli nestuji za to se
presunout do jineho cloudu.

Kdyz si virtualizuju sam, tak je to jako u vseho. Je potreba pochopit
princip a podle toho udelat systemovy design, ktery proste bude
technicky fungovat alespon "good enough" a bude to mit dalsi benefity,
jake je vysoka dostupnost, manageabilita, recoverabilita, bezpecnost,
a v neposledni rade i cena. K tomu technickemu rozhodovani je potreba
tusit kde jsou technologicke limity. No a pak to otestovat a nejakou
dobu ten nadesignovany technologicky system provozovat pro mene
kriticke aplikace, nez tomu uverim a nasadim to pro vice kriticke
aplikace.

> Mejte hezky den.
> Zdenek

Mozna uz je cas se zeptat.
Je tu nekdo kdo provozuje FreeBSD bbhyve virtualizaci pro neco trosku
produkcnejsiho a ma s tim nejakou provozni zkusenost?

David.