Az OpenStack szakértők segítségét szeretném kérni a címben említett témában. Az egyik speciális erőforrástípus esetében felmerült, hogy a nova placement logikában vegyük figyelembe a sávszélességet (pontosabban az adott gép maximális sávszélességét) is, mert garantálni kellene igény szerinti mennyiséget. Tehát ha van egy Compute host-od, amiben van 2x10G NIC, akkor mondjuk 10 darab 1G igényű VM-nél ne kerüljön több rá. Első körben oversubscription nem érdekel, ez lehetne későbbi improvement, ha van egy baseline, és itt-ott van teaming is. Most nem nagyon okoskodunk bele a default placement-be, az egyetlen dolog ami pluszban van az anti-affinity a clusterelt megoldások esetén.
Lehet rossz helyen nézelődök, de egy napos keresgélés után azt látom, hogy nincs ilyen megoldás készen, ami fura tekintve, hogy elvileg sok szolgáltató használ OpenStack-et és a BW garancia szinte mindenhol alap. A gondom az, hogy a bejáratott host modellek esetében mindig a NIC a szűk keresztmetszet (RAM meg CPU van bőven) tehát a fenti példánál maradva 10 gép nem pörgeti ki az összes erőforrást és jöhetne rá még több később, ami nem ideális.
A mostani ötletem elég favágó: csinálni kell egy-két új AZ-t, amiben csak olyan gépek lennének, amikben kevesebb a RAM, CPU és ide csak ez a speciális típus kerülhetne, és mire elérjük a BW szempontjából elméleti maximumot addigra kipörög a többi erőforrás és a probléma megoldja önmagát.
Ismertek erre szép megoldást? Merre érdemes nézelődnöm? Vagy van ilyen megoldás csak én vagyok vak, és a lenti dolgok inkább a dinamikus BW scheduling-re vonatkoznának (ami nekem nem kell)?
https://specs.openstack.org/openstack/nova-specs/specs/stein/implemente…
https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum…
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.h…
Hozzászólások
szokas szerint az openstackesek megint urhajot akartak epiteni de csak kozepes porbafingas lett belole, mint szinte mindig.
a specek nem csak dinamikus bwvel foglalkoznak, atolvasva oket az egyik elokeszitette hogy a placement API kiszolgalja a neutron fele a bandwidth helyzetet, majd kesobb bekerult hogy ez frissul akkor, ha frissited a port qos allokaciojat, illetve a nova APIjaba 2.72-tol bekerult hogy tudjon ilyen portot kerni. tovabba:
namost mivel openstackben ugye a VM inditas folyamata az, hogy a scheduler valaszt a gepet, majd a gepen futo nova processz megkeri a neutront hogy allokaljon egy portot oda, igy persze, hogy nem tudjak garantalni... amibol nyilvan vicces dolgok lesznek, hiszen a neutron mar placement API aware, igy majd jol eldobja a port kerest, hogy nem tudja teljesiteni, amitol a scheduling keres elszall, es jon a retry. ha 3 gepen eljatssza, akkor meg a juzer VMje nem indul.
szoval nem tevedtel, nincs ilyen scheduler jelenleg, hiaba vannak hozza alul a dolgok. megneztem a victoria/wallaby nova speceket, de nincs is meg spec erre. viszont nem tunik neheznek. megirod? :)
Köszi szépen, akkor jól sejtettem. Nem, nem hiszem, hogy sikerülne megírni :)
A taknyolási javaslatomra nem reagáltál; szerinted lehet valamit okoskodni AZ-vel és resource assignment-el? Mondjuk azt, hogy minden igény 1G és fogok 4 megszokott gép konstrukciót egy projectben külön AZ-ben, ahol csak annyi erőforrás van kiajálva, ami ha elfogy, akkor elértük a cél VM számot BW ügyileg. Ha műküdne, akkor lehetne fizikailag is kevesebb cucc benne.
Vagy ez ökörség?
megnezem ma este/holnap a belso placement APIt a scheduler oldalrol, es valaszolok. :)
abszolut nem troll hozzaszolas: ebayrol a kidobott 40 gigas cuccok annyira olcsoak, hogy en fejlesztenem a BWt. 2x25g mellett nalunk szinte sosem a hypervisor a szuk keresztmetszet jelenleg. ha az lenne, upgradelnenk :)
Nem vettem volna trollkodásnak, 25G kártyáról van szó amúgy (10-et is tud persze), csak 10-el könnyebb számolni bármilyen példában.
nem felejtettem el!:)
Rendben, köszi, ahogy az időd engedi, mert egyelőre ez nem akut probléma, inkább csak optimalizálás lenne.
Elolvastam a releváns dokumentációt és a "specs" alatt nem láttam én sem semmit, csak csomó proposal-t (sok ticket amúgy magyar fejlesztőhöz van rendelve ebben a témában), viszont találtam egy ilyet:
"But before we hit the road, I wanted to draw attention to the latest OpenStack upstream release. The Train release continues to showcase the community’s drive toward offering innovations in OpenStack. But given all the technology goodies (you can see the release highlights here) that the Train release has to offer, you may be curious about the features that we at Red Hat believe are among the top capabilities that will benefit our telecommunications and enterprise customers and their uses cases. Here's an overview of the features we are most excited about this release.
...
In this latest OpenStack release, features include QoS management that enables IT admins to set minimum and maximum bandwidth as well as bandwidth-aware scheduling. This helps customers avoid NIC overcommitment, as each virtual machine declares a bandwidth consumption QoS limit so, the Nova scheduler doesn’t overcommit any Neutron physical NIC.
"
Viszont sem a highlight-ban, sem a release notes-ban nincs explicit ez benne, hogy "bandwidth aware scheduling" csak Nova alatt van annyi, hogy a Train-ben lehet ilyen VM-et cold migrálni és átméretezni. Legalább abban megerősített, hogy a feature neve hivatalosan is "bandwidth-aware scheduling", mert amikor a post-ot nyitottam csak tippeltem.
Szóval most szétnézek a Train-ben és közben összeszedem hol lehet ez probléma egyáltalán (tippre 1Gbgps+).
azota se neztem meg, shame on me!