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 <[email protected]> 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. -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
